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INITIAL  DESIGN  AND  EXPERIMENTAL  IMPLEMENTATION  OF 
THE  TRAFFIC  ADVISORY  SERVICE  OF  ATARS 


1.0  PROJECT  OVERVIEW 

The  Automatic  Traffic  Advisory  and  Resolution  Service  (ATARS)  is  a 
ground-based  collision  avoidance  system  which  has  evolved  from  the  earlier 
concept  of  Intermittent  Positive  Control  (IPC).  It  utilizes  surveillance  data 
from  the  Discrete  Address  Beacon  System  (DABS)  [1],  computes  traffic 
advisories  and  collision  warnings  using  a  ground  computer  independent  of  the 
ATC  computer  system,  and  delivers  these  messages  to  aircraft  via  the  DABS 
data-link.  ATARS  provides  both  a  traffic  advisory  and  a  resolution  (collision 
avoidance)  service  to  aircraft  equipped  with  a  DABS  transponder,  an  altitude 
encoder  (mode  C),  and  an  ATARS  display. 

Flight  testing  of  the  otiginal  IPC  algorithm  demonstrated  the  usefulness 
of  the  traffic  advisory  portion  of  IPC  (also  called  the  Proximity  Warning 
Indicator  or  PWI)  as  an  aid  to  visual  acquisition.  However,  the  flight  tests 
also  pointed  up  the  potential  benefits  that  might  be  derived  from  a  more 
complete  traffic  advisory  service,  especially  one  that  could  aid  the  pilot  in 
threat  assessment  as  well  as  in  visual  acquisition. 

1.1  Background 

The  1969  DOT  Air  Traffic  Control  Advisory  Committee  (ATCAC)  recommended 
the  development  of  DABS  to  obtain  improved  surveillance  and  an  integral  data 
link.  It  also  recommended  the  development  of  a  ground  based  collision 
avoidance  system  based  on  DABS  that  would  provide  traffic  advisories  as  well 
as  commands  to  resolve  hazardous  encounters.  The  initial  development  of  this 
IPC  system  was  the  responsibility  of  the  MITRE  Corporation.  During  1974  to 
1976  Lincoln  Laboratory  conducted  a  major  flight  test  activity  using  the  DABS 
Experimental  Facility  (DABSEF).  The  results  of  this  effort  were  documented  In 
a  report  [2]  that  defined  deficiencies  in  the  tested  IPC  system  and 
recommended  needed  improvements  to  both  the  advisory  and  resolution  functions. 
Now  called  ATARS,  this  collision  avoidance  system  is  undergoing  redesign. 

MITRE  is  responsible  for  the  improvements  to  the  resolution  service,  while 
Lincoln  Laboratory  is  responsible  for  the  development  of  an  improved  traffic 
advisory  service. 

Two  main  results  came  out  of  the  IPC  test  flight  program.  The  first  was 
that  the  Proximity  Warning  Indicator  (PWI)  service  provided  help  to  the 
pilots,  producing  a  six-fold  increase  in  the  visual  acquisition  of  proximate 
and  threatening  aircraft.  The  second,  however,  was  that  pilots  felt  the  need 
for  more  specific  information  than  simply  the  bearing  and  relative  altitude 
zone  provided  by  PWI.  Without  explicit  information  on  aircraft  range, 
heading,  and  velocity,  the  pilot  was  unable  to  make  either  a  threat  assessment 
or  a  determination  of  a  safe  maneuver.  Since  this  additional  information  is 


available  in  the  ATARS  ground  computer,  it  was  reasonable  to  conceive  of 
redesigning  the  uplink  messages  to  include  it. 

The  objective  of  the  Lincoln  ATARS  effort  was  the  design  of  a  traffic 
advisory  service  that  complements  the  ground  based  resolution  service  and 
is  compatible  with  the  other  applications  being  developed  for  the  DABS  data 
link.  The  main  technical  issue  was  the  construction  of  a  set  of  message 
formats  that  provides  the  pilot  with  all  information  he  requires  while 
minimizing  data  link  loading.  Furthermore,  this  message  set  had  to  support  a 
wide  spectrum  of  onboard  equipment,  from  a  simple  ring  of  lights  to  a 
sophisticated  graphics  system. 

The  system  design  effort  of  the  Lincoln  ATARS  program  has  now  been 
completed.  The  first  issue  addressed  was  the  determination  of  the  set  of 
information  a  pilot  would  require  to  properly  evaluate  each  encounter.  After 
the  information  content  was  defined,  a  set  of  messages  for  transmission  of 
this  information  tn  che  aircraft  was  designed.  The  formats  of  these  messages 
were  constrained  by  two  main  considerations:  (1)  efficiency  of  packing  in 
order  to  minimize  data  link  loading,  and  (2)  ease  of  support  of  low  end 
onboard  displays.  Complex  displays,  with  sophisticated  microprocessors,  can 
handle  any  message  class;  unsophisticated  equipment,  though,  can  only  be 
expected  to  handle  a  few  message  types,  and  the  variables  needed  in  each  must 
be  directly  available  in  a  usable  format. 

A  development  airborne  graphics  display  system  was  built  in  order  to 
support  the  validation  of  the  traffic  advisory  service  and  other  data  link 
applications.  This  system,  consisting  of  a  microprocessor  to  process  messages 
and  a  color  weather  radar  CRT  to  display  the  encounter  information,  has  been 
programmed  and  installed  in  test  aircraft  [3].  It  is  currently  undergoing 
ATARS  fligit  testing  at  the  FAA  Technical  Center.  Lincoln  is  completing  a 
second  ve'sion  of  display  based  on  a  less  capable  3”  CRT  in  order  to  support 
validation  testing  in  general  aviation  class  aircraft.  The  same 
microprocessor  system  already  built  will  support  this  new  display. 

1.2  Traffic  Advisory  Service  Objectives 

The  two  main  objectives  of  the  ATARS  traffic  advisory  service  are:  to 
aid  the  pilot  in  visually  acquiring  proximate  and  threatening  aircraft,  and  to 
aid  him  in  performing  accurate  threat  assessment  on  those  aircraft.  The 
service  will  also  provide  blunder  protection  by  providing  information  on 
nearby  aircraft  that  would  assist  the  pilot  in  avoiding  maneuvers  which  could 
create  a  collision  hazard. 

See-and-avoid  has  been  the  primary  protection  against  mid-air  collisions 
for  pilots  flying  under  both  Visual  Flight  Rules  (VFR)  and  Instrument  Flight 
Rules  ( IFR)  in  Visual  Meterological  Conditions  (VMC).  At  present,  controllers 
provide  "traffic"  advisories  to  VFR  on  a  work  permitting  basis  and  "safety” 
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advisories  to  IFR  pilots  on  a  first  priority  basis.  In  either  case,  however, 
advisory  issuance  is  contingent  upon  the  awareness  of  the  controller  of  the 
unsafe  or  threatening  situation.  Thus,  pilots  may  not  always  receive  all  of 
the  advisories  they  desire,  and  those  received  may  not  always  be  received  in 
t  ime. 


The  ATARS  traffic  advisory  service  will  improve  the  see-and-avoid 
approach  in  the  following  respects: 

1.  all  necessary  advisories  will  be  provided  on  a  full-time  basis 
independent  of  controller  workload 

2.  most  advisories  will  be  provided  early  enough  for  the  pilot  to 
have  sufficient  time  to  assimilate  the  information  and  safely 
react  to  the  situation 

3.  the  potential  for  human  error,  caused  by  controllers  having 
insufficient  time  to  study  each  situation,  will  be  eliminated 

4.  more  information  with  greater  accuracy  will  be  provided 
on  each  situation  than  is  presently  available  from 

the  controller 

The  additional  and  more  timely  information  is  especially  important  since 
increased  aircraft  velocities  will  require  accurate  threat  assessment  at  the 
limits  of  visual  acquisition. 

1.3  Scope 

This  document  presents  a  unified  ground/data  link/airborne  system  for 
implementing  the  traffic  advisory  service  of  ATARS.  The  purpose  of  this 
service  is  to  inform  pilots  of  all  potential  conflict  encounters  that  exist, 
or  may  develop,  due  to  nearby  aircraft  and  to  aid  him  in  avoiding  blunders. 
Threat  and  proximity  advisories  are  transmitted  from  ground  sensors  to  the 
aircraft  via  the  DABS  data  link  as  COMM-A  messages.  The  resolution  service  of 
ATARS,  which  supplies  advisories  to  pilots  to  help  avert  serious  encounters, 
will  not  be  described  in  this  document. 

The  key  blocks  of  the  coordi  i.'ted  ATARS  system  are: 

1.  a  ground  tracker  to  predict  future  positions  of  all  aircraft 

2.  rules  for  determining  when  threat  and  proximity  advisories  are 
required 

3.  a  set  of  uplink  messages  that  can  provide  all  information 
required  by  all  classes  of  ATARS  users 


4.  rules  for  determining  when  to  send  each  uplink  message 


5.  a  range  of  onboard  equipments  to  present  ATARS  information 
to  the  pilot 

6.  algorithms  for  each  such  onboard  system  to  define  how  each 
ATARS  message  is  processed  and  displayed 

This  document  will  cover  in  detail  all  of  these  areas.  The  detailed  onboard 
algorithms  apply  only  to  the  graphic  display  system  built  by  Lincoln  but  are 
representative  of  those  that  would  be  used  in  any  similar  sophisticated 
display. 
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2.0  ATARS  GROUND  SYSTEM 

Nearly  all  of  the  additional  quantities  required  by  the  ATARS  traffic 
advisory  service  already  existed  in  the  IPC  computer.  Thus,  few  ground 
algorithm  modifications  were  needed  to  -.upport  the  improved  traffic  advisory 
service.  This  chapter  presents  and  describes  the  changes  that  were  required. 
Since  MITRE  is  responsible  for  modifying  the  ground  system  to  meet  these 
requirements,  no  implementation  details  are  provided. 

2.1  Traffic  Advisory  Determinations 

An  ATARS  traffic  advisory  message  is  generated  for  two  different  types  of 
encounters:  proximity  and  threat.  Proximity  messages,  previously  named 
ordinary  PWI’s,  inform  the  pilot  of  all  aircraft  in  the  nearby  airspace  not 
currently  viewed  as  threats.  Threat  messages,  previously  called  flashing 
PWI’s,  are  only  sent  for  aircraft  whose  present  flight  path  would  bring  them 
into  conflict  with  the  subject  aircraft.  The  latter  encounters  are  thus  more 
urgent,  and  may  require  pilot  action  or  flight  constraints  to  avoid  collision. 
More  serious  threat  encounters  are  accompanied  by  resolution  messages, 
previously  called  commands. 

A  proximity  advisory  is  generated  for  any  aircraft  whose  horizontal  and 
vertical  separations  from  the  subject  aircraft  are  both  within  specified 
limits.  The  vertical  limit  is  always  2000  feet,  but  the  horizontal  limit  (H) 
is  a  function  of  the  two  aircraft  speeds: 

H’  =  SQRT  [2*900*(V12  +  V22)]  nni 
Vj,  V2  in  nmi/sec 

H  =  Max  (2,H')nrai 

This  limit  grows  linearly  with  aircraft  speeds,  going  beyond  the  minimum  2 
nautical  miles  when  both  aircraft  exceed  120  knots  and  being  5  miles  when  both 
aircraft  are  traveling  at  300  knots. 

A  threat  advisory,  rather  than  a  proximity  advisory,  is  sent  when  the 
other  aircraft  is  closing  on  the  subject  aircraft,  and  the  expected  time  until 
closest  approach  (x)  is  within  50  seconds.  The  critical  time  is  calculated  as 
•  • 
p/p,  where  P  is  the  inter-aircraft  range  and  p  is  the  component  of  the 
relative  velocity  along  the  relative  bearing  angle.  Although  the  actual 
criteria  needed  to  create  a  threat  situation  are  quite  complex,  an  approximate 
simplification  is  that  all  of  the  following  three  conditions  must  be  met: 

1.  the  horizontal  component  of  x  is  within  50  seconds,  ££ 

the  current  horizontal  separation  is  less  than  1.2  miles;  and 
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2.  the  vertical  component  of  t  is  within  50  seconds,  or 

the  current  vertical  separation  is  less  than  1000  feet;  and 


3.  the  projected  closest  approach  range  is  less  than  1.2  mile. 


These  numbers  are  all  experimental  and  subject  to  change. 

A  more  critical  threat  situation  also  triggers  a  resolution  advisory, 
which  is  a  command  the  pilot  is  instructed  to  follow  in  order  to  avoid  a 
collision  or  near  miss.  Resolution  advisories  can  be  positive  (e.g.,  climb  or 
turn  right),  negative  (e.g.,  don't  descend  or  don't  turn  left),  or  vertical 
speed  limits  (e.g.,  limit  climb  to  500  feet  per  minute).  More  than  one  such 
advisory  can  exist  at  a  time  if  the  situation  complexity  sc  warrants.  The 
issuance  of  these  advisories  is  controlled  by  the  same  three  criteria  as  the 
threat  advisory,  although  with  smaller  values  of  x  and  separation. 

2.2  Most  Critical  Encounter 


Many  of  the  unsophisticated  displays  to  be  employed  for  ATARS  will  only 
be  able  to  present  complete  information  on  the  most  critical  encounter. 

Rather  than  requiring  such  low  cost  displays  to  have  the  computational  power 
to  determine  which  encounter  is  most  important  whenever  two  or  more  exist,  the 
ground  system  is  required  to  flag  the  most  critical  encounter  each  scan  via 
the  bit  provided  for  that  purpose  in  each  position  message. 

In  addition,  the  ground  is  required  to  list  all  other  encounters  in  order 
of  priority.  This  ordering  becomes  relevant  on  any  scan  in  which  the  data 
link  capacity  is  exceeded  by  the  number  of  messages,  ATARS  and  non-ATARS, 
waiting  for  transmission.  In  such  cases,  the  ATARS  encounters  should  be 
transmitted  in  order  of  importance. 

Both  of  these  functions  are  performed  by  introducing  a  scoring  function 
for  encounters.  The  first  scoring  rule  is  that  any  threat  encounter 
associated  with  a  resolution  advisory  outranks  any  threat  encounter  not 
associated  with  such  an  advisory,  and  that  any  threat  encounter  outranks  any 
proximity  encounter.  Encounters  within  each  of  the  three  classes  are  then 
scored  as  follows,  where  a  lower  score  implies  a  higher  ranking: 

Proximity: 

score  =  range  -  horizontal  separation  +  5  times  vertical  separation 

Threat  (either  class): 

score  =  horizontal  x 

ties  are  broken  by  range  (defined  as  above) 

Not  all  threats  are  detected  via  a  horizontal  x.  For  those  found  from  the 
maneuvering  target  logic,  a  pseudo  x  is  computed  as  horizontal  range  divided 
by  the  sum  of  the  aircraft  velocities;  for  diverging  threats,  x  is  set  to  a 
large  constant  (and  thus  range  selects  between  multiple  ones). 
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The  most  critical  encounter  will  generally  be  the  one  with  the  lowest 
score.  However,  once  an  encounter  is  labelled  most  critical,  it  should  remain 
so  for  at  least  two  scans.  This  requirement  prevents  the  screen  flicker  that 
wouj-d  occur  by  rapid  changes  of  most  critical  encounters,  and  should  provide 
the  pilot  with  enough  time  to  assimilate  the  encounter  data.  Ihus,  the  rules 
for  one  encounter  replacing  another  as  the  most  critical  are  the  following: 

1.  an  encounter  of  one  class  (defined  above)  will  always  replace 
one  of  a  lower  class 

2.  an  encounter  must  be  most  critical  for  two  or  more  scans  before  it 
can  be  replaced  by  one  of  the  same  class 

2.3  ATARS  Tracker 

The  tracker  used  for  ATARS  screening  and  prediction  is  a  smoothed  X-Y 
tracker  with  turn  detection.  The  smoothing  constants  have  been  selected  to 
provide  best  estimates  of  the  heading  and  velocity  of  each  aircraft,  since 
these  quantities  are  more  important  than  position  for  ATARS  functions.  The 
turn  detector  indicates  whether  the  aircraft  is  in  a  turn.  If  a  turn  is 
detected,  different  smoothing  constants  are  employed  to  better  match  the 
changed  flight  dynamics,  and  future  projections  are  based  on  modifications  to 
the  current  heading. 

The  basic  tracker  for  ATARS,  originally  designed  for  IPC,  will  support 
the  expanded  traffic  advisory  service  if  one  improvement  is  added:  an 
estimate  of  the  actual  turn  rate,  not  just  a  yes/no  turn  indication.  This 
quantity,  provided  to  sophisticated  users,  permits  their  displays  to  be 
accurately  updated  even  when  ground  data  is  missing.  Since  a  cross-track 
deviation  is  already  being  computed,  the  additional  turn  rate  quantity  can  be 
calculated  with  a  minor  mathematical  addition.  Figure  1  presents  the  geometry 
that  applies  at  the  beginning  of  a  turn,  3long  with  the  turn  rate  equation.  By 
employing  the  heading  tuat  existed  two  or  more  scans  ago  for  the  cross  track 
deviation  computation,  rather  than  the  most  recent  one,  a  more  accurate  turn 
rate  can  be  found.  This  modification  simply  requires  extra  track  file  storage 
for  additional  heading  fields. 

Once  a  turn  has  been  established,  future  turn  rate  calculations  can  be 
made  just  by  noting  the  heading  change  that  occurs  each  scan  after  the  tracker 
has  performed  its  turn  state  smoothing.  Heading  values  are  required  in  any 
event  for  traffic  advisories,  so  no  additional  work  is  needed.  The  turn  ends 
when  no  further  heading  change  is  n^Led. 

2.4  Ground  Processing  Requirements 

The  ground  system  must  maintain  all  information  that  is  required  to 
support  the  various  ATARS  functions.  Thus,  the  positions  of  all  aircraft  must 
be  kept  to  determine  proximity  encounters.  In  addition,  the  projection 
parameters  required  to  locate  threat  encounters,  namely  aircraft  headings, 
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Fig.  1.  Turn  Rate  Computation. 
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turns,  and  velocities,  must  be  maintained.  Finally,  all  information  that  is 
transmitted  in  any  uplink  message  (as  defined  in  section  4.1)  must  be  present 
in  the  ground  computer  or  be  computable  from  quantities  that  are. 

Each  time  the  ground  system  determines  that  a  new  encounter  has  begun, 
either  proximity  or  threat,  it  must  assign  a  track  number  to  the  encounter  and 
commence  the  transmission  of  the  appropriate  uplink  messages.  The  ground  must 
then  check  the  status  of  this  encounter  every  scan,  and  continue  the  message 
stream  for  that  track  number  as  long  as  the  geometric  relationship  of  the  two 
aircraft  satisfies  the  advisory  rules.  Finally,  when  the  encounter 
terminates,  one  further  message  must  be  sent,  the  end  message.  The  track 
number  is  then  available  for  use  with  another  encounter. 

The  implication  of  these  rules  is  that  the  ground  must  maintain  encounter 
pair  records,  with  track  numbers,  on  all  proximity  and  threat  encounters, 
instead  of  just  on  resolvable  encounters  as  in  IPC.  The  transmission  of  an  end 
message  after  the  encounter  has  terminated  (to  inform  sophisticated  users  they 
may  drop  their  file)  is  also  a  new  requirement.  Both  of  these  augmentations, 
though,  are  simple  and  straightforward  to  implement. 

In  order  to  provide  a  meaningful  display,  the  number  of  encounters 
presented  to  the  pilot  must  be  limited  to  a  reasonable  number.  Thus,  the 
track  number  has  been  implemented  as  only  a  3-bit  quantity.  Even  the  eight 
encounters  this  provides  is  probably  beyond  the  useful  bound,  and  could  lead 
to  more  information  than  can  be  assimilated  by  the  pilot.  The  ground  system 
must  insure  that  all  threats  are  given  track  numbers,  even  if  ongoing 
proximities  are  lost  in  the  event  of  more  than  eight  encounters.  Also,  it 
must  order  the  uplink  messages,  most  important  to  least  important,  so  that  any 
not  delivered  on  a  scan  are  the  least  critical. 

2.5  Multisensor  Handoff  Procedures 


When  ATARS  operates  in  a  multisensor  environment,  aircraft  will 
frequently  cross  sensor  coverage  boundaries  during  the  time  they  are  receiving 
traffic  advisories,  even  when  they  are  under  resolution  advisories.  Thus, 

MITRE  has  defined  handoff  login  for  the  ATARS  system.  This  logic  uses  three 
zones  of  coverage,  as  illustrated  by  Figure  2,  with  three  different  methods  of 
ATARS  service.  This  section  outlines  the  sequence  of  actions  that  occur  for 
the  normal  order  of  transition  shown  in  the  diagram;  other  situations  are 
handled  by  similar  algorithms. 

Initially,  the  aircraft  is  processed  by  the  ATARS  logic  of  sensor  A,  and 
that  sensor's  data  link  is  used  to  uplink  the  ATARS  messages.  When  the  uplink 
boundary  is  crossed,  message  transmission  responsibility  is  turned  over  to 
sensor  B.  However,  the  sensor  A  ATARS  logic  is  still  controlling  the 
encounters,  and  routing  the  messages  to  sensor  B.  Finally,  when  the  ATARS 
boundary  is  crossed,  sensor  B  becomes  responsible  for  both  the  formation  and 
transmission  of  the  ATARS  messages. 
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Fig.  2.  Handoff  Geometry 


A  completely  smooth  transition  of  ATARS  authority  can  only  occur  if 
sensor  A  were  to  send  sensor  B  all  its  data  on  all  open  encounters.  The 
current  ATARS  system  only  sends  such  information,  in  the  form  of  conflict 
tables,  if  a  resolution  advisory  is  in  effect.  Thus,  only  some  threat 
encounters,  and  no  proximity  ones,  would  be  covered.  Increasing  the 
requirement  to  handle  all  encounters  could  add  a  substantial  load  to  the 
inter-sensor  communications  link.  However,  by  only  requiring  all  threat 
encounters  to  be  handed  off,  and  ignoring  the  less  critical  proximity 
encounters,  the  increased  load  should  be  negligible.  The  change  needed  in  the 
existing  ATARS  ground  logic  for  this  method  of  operation  is  the  construction 
and  maintenance  of  conflict  tables  for  all  threats,  not  just  those  requiring 
resolution.  This  modification  can  be  made  at  a  later  date  if  found  to  be 
desirable. 

A  minor  modification  to  the  ATARS  conflict  table  format  is  required  to 
permit  the  avionics  equipment  to  smoothly  handle  these  transitions.  Namely, 
the  track  number  used  by  sensor  A  in  its  uplink  messages  has  to  be  included. 
Then  sensor  B  can  employ  this  same  number  for  the  encounter,  and  onboard 
display  continuity  is  assured. 
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3.0  ATARS  DATA  LINK  SYSTEM 


The  medium  used  for  transmitting  information  from  the  ATARS  ground 
computer  to  the  onboard  display  system  is  the  DABS  data  link.  The  basic  data 
link  entity,  the  COMM-A,  can  accommodate  a  message  as  large  as  48  bits.  Thus, 
if  the  totality  of  ATARS  information  is  divided  into  48  bit  segments,  it  can 
be  sent  to  the  aircraft  via  a  series  of  COMM-A' s. 

The  more  information  about  each  encounter  sent  to  the  aircraft,  the  more 
complete  and  accurate  the  display  can  be.  Unfortunately,  the  number  of 
COMM-A' s  available  to  ATARS  on  each  scan  is  limited.  Thus  there  is  a  benefit 
attached  to  reducing  the  information  set.  Less  important  information, 
quantities  nearly  constant  over  the  encounter,  and  quantities  calculable 
onboard  are  all  subject  to  deletion. 

This  section  discusses  the  ramifications  of  the  information/link- 
occupancy  tradeoff. 

3.1  ATARS  Message  Philosophy 


A  variety  of  different  message  formats,  with  corresponding  message 
utilization  protocols,  can  be  employed  to  implement  ATARS.  The  proper  choice 
of  system  can  be  made  only  after  the  following  two  system  philosophy  questions 
have  been  answered: 

1.  should  all  ATARS  users  be  provided  with  the  same  information,  or 
should  classes  of  users  be  defined,  with  sophisticated  users 
receiving  more  data  than  unsophisticated  users? 

2.  should  complete  information  be  provided  for  both  proximity  and 
threat  encounters,  or  should  proximity  encounters  be  less  fully 
specified  than  threat  encounters,  or  should  all  encounters 

be  specified  by  the  minimum  data  subset? 

Expected  data  link  loading  conditions  play  a  critical  role  in  these  decisions, 
although  the  role  of  ATARS  in  the  spectrum  of  ATC  functions  is  also  important. 

The  main  advantage  of  treating  all  users  alike  is  system  simplicity:  the 
ground  needs  only  one  message  protocol,  and  no  method  is  required  for 
determining  aircraft  user  type.  Its  disadvantage  is  that  either 
unsophisticated  users  are  sent  more  information  than  they  require,  and  hence 
some  data  link  capacity  is  wasted,  or  sophisticated  users  are  denied  some 
useful  information,  and  hence  some  display  accuracy  is  sacrificed. 

Defining  two  or  more  ATARS  user  classes  permits  the  tailoring  of 
messages  to  the  user  needs.  In  particular,  users  desiring  only  resolution 
service  and  not  equipped  for  traffic  advisories  would  require  almost  no 
messages,  while  unsophisticated  users  could  be  serviced  by  shorter  messages 
than  sophisticated  ones.  This  method  of  operation,  of  course,  complicates 
the  ground  system,  and  leaves  ATARS  open  to  more  and  more  classes  being 


introduced.  More  important,  though,  it  could  lead  to  severe  problems  if  an 
error  were  made  in  an  aircraft  user  type  determination.  To  prevent  dangerous 
onboard  misinterpretation  of  information,  or  loss  of  required  data,  the 
messages  themselves  must  be  made  fail-safe  (or  at  least  fail-soft).  This  means 
that  a  user  of  one  class,  receiving  a  message  meant  for  a  user  of  a  different 
class,  could  still  produce  a  correct  and  usable  display.  This  requirement 
eliminates  the  possibility  of  suppressing  traffic  advisories  to  some  users, 
since  any  aircraft  erroneously  typed  as  a  resolution-only  user  would  receive 
no  advisories.  Sophisticated  and  unsophisticated  users,  though,  can  be 
supported  in  a  fail-soft  manner  as  described  below. 

A  proximity  encounter,  by  definition,  is  less  critical  than  a  threat 
encounter.  Thus,  it  is  not  unreasonable  to  provide  less  detailed  position  and 
motion  information  in  its  message.  Furthermore,  the  presence  of  resolution 
advisories  when  a  threat  becomes  dangerous  means  that  some  loss  of  accuracy 
even  in  threat  encounters  can  be  tolerated.  Thus,  any  of  the  three 
alternatives  suggested  above  in  question  2.  may  be  proper,  and  studies  of 
system  performance  and  data  link  loading  are  required  before  an  optimum  choice 
can  be  made. 

3.2  Encounter  Information  Options 

The  ATARS  data  that  must  be  transmitted  to  specify  a  proximity  encounter 
is  the  current  position  and  state  of  the  proximate  aircraft.  As  shown  in  the 
first  column  of  Figure  3,  if  total  available  information  is  to  be  provided, 
one  entire  COMM-A  message  would  be  needed.  However,  as  shown  in  the  next 
column,  by  cutting  back  to  the  smallest  acceptable  data  subset,  only  half  a 
COMM-A  would  be  needed.  Therefore,  two  different  proximity  encounters  could 
be  described  in  a  single  COMM-A,  and  link  loading  would  be  reduced. 

The  minimum  subset  eliminates  velocity,  turn  type,  and  vertical  speed. 

As  will  be  shown,  the  former  is  always  given  in  the  message  at  the  start  of  an 
encounter  and  should  change  little  during  the  encounter;  the  latter  two  are 
deemed  of  less  importance  to  the  pilot.  The  track  number  is  also  lost, 
thereby  requiring  a  sophisticated  user's  onboard  computer  to  perform 
positional  correlation.  Finally,  a  less  precise  heading  is  provided. 

A  sophisticated  graphic  display  will  present  a  relative  motion  picture 
for  threat  encounters,  thereby  helping  the  pilot  to  visualize  the  forthcoming 
changing  geometry  between  his  and  the  threat  aircraft.  Thus,  a  complete 
threat  specification  must  include  information  on  both  the  current  position  of 
the  other  aircraft  and  its  projected  position  at  the  time  of  closest  approach. 
As  shown  in  the  third  column  of  the  figure,  this  total  set  of  information 
would  require  two  full  COMM-A  messages.  However,  as  shown  in  the  last  column, 
it  is  possible  to  define  a  basic  set  of  threat  information  that  would  fit 
within  a  single  COMM-A. 
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Fig.  3.  Encounter  Information  Options. 
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The  basic  subset  has  eliminated  velocity,  own  heading,  and  all  closest 
point  of  approach  quantities  other  than  miss  distance.  The  former  two  are 
included  in  other  message  types  sent  less  frequently.  The  closest  point  of 
approach  quantities,  on  the  other  hand,  are  computable  from  the  other  data 
fields,  although  with  potentially  significant  error.  The  Appendix  provides 
the  details  of  these  computations,  as  well  as  their  expected  accuracies. 

It  should  be  noted  that  even  the  basic  threat  data  is  still  far  more 
complete  than  that  provided  for  by  the  basic  proximity  set.  This  is  in 
recognition  of  the  more  serious  nature  of  threat  encounters.  If  this  were  r<  . 
considered  relevant,  and  if  relative  motion  displays  were  not  required,  then 
the  same  half  COMM-A  subset  could  be  used  for  threats  as  for  proximities. 

3.3  Possible  ATARS  Message  Protocols 

This  section  defines  four  possible  protocol  systems  that  were  considered 
for  ATARS,  for  two  user  classes,  that  cover  the  range  of  systems  implied  by 
the  previous  section's  options.  The  message  formats  to  support  these  systems 
are  detailed  in  the  next  chapter.  By  considering  all  the  message  types 
specified  there,  a  decision  on  the  "correct”  choice  can  be  postponed  until 
tests  have  been  run.  Once  a  system  is  chosen,  of  course,  it  will  be  the  only 
one  employed. 

Figure  4  presents  the  four  sample  ATARS  protocol  systems,  using  the 
encounter  message  requirements  for  their  definition.  A  Single  Proximity 
Message  presents  complete  data  on  one  proximity  encounter,  while  a  Dual 
Proximity  Message  presents  basic  data  on  two  different  proximity  encounters;  a 
Basic  Threat  Message  presents  the  basic  threat  data  subset,  while  the 
Supplementary  Threat  Message  presents  the  remaining  data  for  a  complete  threat 
specification.  The  first  three  systems  treat  all  users  equally,  while  the 
last  one  differentiates  between  sophisticated  and  unsophisticated  users. 

The  first  protocol  system,  named  Full  Information,  employs,  for  all 
users,  messages  containing  -full  information  for  all  encounters,  one  for  each 
proximity  and  two  for  each  threat.  Thus,  any  piece  of  information  that  could 
be  employed  by  the  onboard  equipment  is  guaranteed  to  be  present.  This  system, 
of  course,  requires  more  COMM-A  transmissions  than  any  of  the  others,  as  shown 
by  Figure  5, 

The  second  system,  named  Basic  Proximity,  provides  only  minimum 
information  for  proximity  encounters  whenever  two  or  more  exist,  but  still 
maintains  full  data  for  each  threat.  Again,  all  users  receive  the  identical 
messages.  This  system  requires  fewer  COMM-A  transmissions  than  the  previous 
one  when  multiple  encounters  exist. 
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Fig.  4.  ATARS  Message  Protocol  Systems. 
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The  final  single  user  class  system,  named  Minimum  Information,  provides 
only’  the  minimum  data  sets  for  all  encounters,  proximity  and  threat.  Thus, 
this  system  requires  the  minimum  possible  number  of  COMM-A  transmissions. 
However,  since  the  closest  point  of  approach  calculations  must  now  be 
performed  onboard,  more  complex  display  software  is  required  under  this 
protocol. 

The  remaining  system  requires  the  ground  to  ascertain  the  type  of  ATARS 
user  represented  by  each  aircraft.  However,  as  described  in  the  next  chapter, 
message  formats  are  designed  to  be  fail-soft.  Thus,  a  user  receiving  the 
wrong  type  of  messages  will  still  be  able  to  function  properly. 

The  Matched  Threat  system  sends  full  information  on  threats  only  to 
sophisticated  users,  with  only  basic  threat  data  sent  to  unsophisticated 
users.  All  users,  of  both  classes,  will  receive  only  basic  proximity  data. 

If  only  a  small  percentage  of  users  are  sophisticated,  this  system  will 
require  very  few  more  COMM-A  messages  than  the  Minimum  Information  one. 
However,  these  few  additional  messages  may  well  provide  a  major  improvement 
for  the  sophisticated  class  of  user. 

Various  other  one  and  two  user  class  systems  could  be  defined.  However, 
since  this  section  was  meant  to  be  representative  and  not  exhaustive,  they 
will  not  be  discussed  here. 

A  key  measure  to  be  used  in  choosing  the  "best”  system,  as  discussed  next 
in  the  recommendations  section,  is  the  number  of  COMM-A  messages  each  system 
requires  for  various  combinations  of  active  encounters.  Figure  5  presented 
this  data  for  a  typical  scan  of  each  case.  As  discussed  below,  encounter 
starts  and  endings  require  special  messages. 

FAA  studies  of  Automated  Radar  Terminal  System  (ARTS)  tapes  and  runs  of 
the  Air  Traffic  Control  Simulation  Facility  (ATCSF)  indicate  that  over  90"  of 
all  encounters  will  be  proximities.  Furthermore,  except  in  very  dense 
environments,  only  one  or  two  such  encounters  will  exist  at  any  time.  All  of 
the  systems  are  identical  for  a  single  proximity  case,  so  Figure  6  presents 
the  different  time  lines  that  apply  for  a  two  proximity  situation.  The  special 
start  and  end  messages  are  discussed  in  the  next  chapter. 

The  systems  also  differ  in  their  time  lines  when  a  threat  encounter  is 

present,  as  shown  in  Figure  7.  Again,  the  start  and  end  scans  are  discussed  in 

the  next  chapter.  Since  proximity  and  threat  encounters  cannot  be  combined 

into  joint  messages,  the  presence  of  one  or  more  proximity  encounter  along 
with  the  threat  would  simply  add  messages  to  the  time  lines. 

3.4  Recommendations 


Subject  to  flight  test  verification,  it  appears  that  the  basic  proximity 
data  set  should  provide  pilots  with  sufficient  data  on  proximate  aircraft. 
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Messages  During  A  Threat  Encounter 


Also,  if  onboard  calculations  of  the  time  to,  and  position  of,  the  point  of 
closest  approach  for  threat  aircraft  provide  accurate  results,  the  basic 
threat  data  set  will  supply  all  information  necessary  for  threat  aircraft 
displays.  Thus,  if  both  of  these  suppositions  are  proven  true,  the  Minimum 
Message  System  is  the  optimum  one  to  choose  for  ATARS.  In  particular,  it 
possesses  the  following  distinct  advantages  over  the  others: 

1.  it  doesn't  require  user  class  determination,  with  its  inherent 
error  possibilities, 

2.  it  is  minimal  in  its  COMM-A  requirements,  and  performs 
significantly  better  in  this  aspect,  than  the  others  considered, 
as  the  encounter  load  grows  and  data  link  loading  becomes 

more  critical 

Before  a  final  choice  was  made,  however,  three  factors  were  considered. 
These  were: 

1.  data  link  loading  and  capacities 

2.  system  flexibility 

3.  cost  to  general  aviation  users 

The  first  issue  was  analyzed  by  MITRE  [4].  System  flexibility  can  imply  many 
factors.  One  of  the  most  important,  though,  would  be  the  ability  to  define 
additional  levels  of  user  equipment  beyond  just  sophisticated  and 
unsophisticated.  By  selecting  a  system  that  treats  all  users  equally,  this 
becomes  quite  simple  to  do.  With  a  two  user  system,  though,  all  new  classes 
would  have  to  be  mapped  into  one  or  the  other  of  the  defined  ones  if 
complexity  is  to  be  avoided.  Finally,  all  options  appear  to  be  able  to  support 
the  very  simplest  user  displays,  so  general  aviation  cost  is  apparently  not  a 
selection  factor. 

Lincoln  recommended  the  initial  selection  of  the  Minimum  Information 
System  for  ATARS,  and  believes  it  should  be  employed  for  flight  tests  and 
submitted  for  avionics  manufacturers  comments.  As  noted  earlier,  the  proposed 
messages  can  support  any  of  the  four  system  protocols  considered.  Therefore, 
one  of  the  other  three  system  protocols  could  be  implemented  if  the  Minimum 
Information  System  is  found  after  flight  testing  to  be  insufficient  for  ATARS 
needs. 
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4.0  ATARS  UPLINK  MESSAGES 


A  large  variety  of  information  is  required  by  the  onboard  ATARS  computer 
and  display  in  order  for  them  to  perform  at  full  capability.  Some  of  this 
information  is  the  same  for  all  encounters,  some  stays  constant  throughout  an 
encounter,  and  some  changes  continually  during  an  encounter.  Also,  proximity 
and  threat  encounters  have  different  data  needs.  Thus,  to  match  these 
characteristics,  a  number  of  different  ATARS  messages  have  been  defined. 

Each  ATARS  message  is  sized  to  fit  within  the  48  data  bits  of  a  DABS 
COMM-A.  Since  the  major  ATARS  data  sets,  such  as  current  aircraft  position 
and  basic  threat  data,  consist  of  24  bits,  two  such  sets  can  fit  within  a 
COMM-A.  This  chapter  first  describes  the  data  sets  currently  defined  in  the 
ATARS  system  now  undergoing  test.  Then  it  presents  the  ATARS  messages  they 
combine  to  form,  and  the  rules  for  selecting  the  proper  ones  to  transmit.  The 
final  section  discusses  possible  future  additions  and  modifications  to  the 
message  set. 

4.1  ATARS  Data  Sets 

The  data  sets  that  have  been  defined  for  initial  ATARS  testing  are 
presented  in  the  following  paragraphs.  All  sets  contain  24  bits  so  that  any 
two  can  be  combined  into  a  single  COMM-A  message. 

4.1.1  Own  Data  (Figure  8) 

The  Own  Data  Set  is  the  only  data  set  not  tied  to  an  encounter.  It  is 
transmitted  on  initial  ATARS  contact  and  updated  subsequently  when  necessary. 
Unsophisticated  avionics  will  ignore  this  message's  presence. 

For  a  sophisticated  user,  this  data  set  is  used  to  specify  the  parameters 
of  motion  of  the  subject  aircraft:  heading,  velocity,  and  turn  rate.  These 
quantities  can  be  displayed  to  provide  the  pilot  a  sense  of  confidence  in  the 
ground  tracker.  More  importantly,  if  onboard  instruments  are  tied  into  the 
ATARS  avionics,  the  errors  detected  in  these  values  can  be  used  to  correct  the 
ATARS  traffic  advisories  for  aircraft  crab  angle.  For  example,  if  the  own 
heading  is  off  by  5°,  then  a  5°  correction  could  be  made  to  all  bearing 
angles.  Also,  a  sophisticated  onboard  computer  will  need  own  velocity  and 
heading  to  compute  the  time  and  position  of  a  threat  encounter's  closest  point 
of  approach. 

The  ATARS  capability  field  is  very  important  if  different  classes  of 
users  are  defined  for  either  the  traffic  advisory  service  (as  discussed  in  the 
previous  section)  or  the  resolution  service. 

Currently  planned  DABS  and  ATARS  multisite  designs  hope  to  ensure  that 
only  one  sensor  is  providing  ATARS  messages  to  any  aircraft  at  one  time.  Some 
operational  modes  and  various  failure  modes,  however,  can  interfere  with  this 
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Bits  Interpretation 
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Referenced  to  magnetic  north 
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7  10  knot  lsb 
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(Two’s  Complement  with  Right 
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2  4  levels  possible  (only  01  used 
at  present) 

1  Multi  (1)  or  Single  (0) 

ATARS  sites  can  uplink  data 

3  1  sec  lsb  added  to  4  seconds 

(thus  4  to  11  seconds  possible) 
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Fig.  8.  Own  Data. 
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assignment  process.  The  seam  bit  informs  the  onboard  computer  whether  unique 
coverage  can  be  guaranteed  at  the  current  location  of  the  aircraft.  If  true, 
message  track  numbers  provide  unique  encounter  labels;  if  not,  onboard 
positional  correlation  of  messages  to  encounters  will  be  required  by 
sophisticated  users. 

Finally,  the  scan  period  provides  the  timing  data  that  is  required  by 
sophisticated  avionics  to  compute  positional  rates  of  change.  Thus,  it  permits 
such  avionics  to  coast  encounters  whose  messages  are  missing  for  a  scan. 

4.1.2  Position  Data  (Figure  9) 

The  Position  Data  Set  is  used  for  all  encounters,  proximity  or  threat,  to 
specify  the  current  position  of  the  other  aircraft  within  the  advisory  airspace 
of  the  subject  aircraft.  As  such,  it  is  the  key  ATARS  data  set.  In  fact, 
except  for  resolution  advisories,  it  supplies  all  the  information  a  simple 
unsophisticated  display  would  need  for  its  presentation. 

The  position  attributes  supplied  by  this  data  set  are  the  relative 
bearing,  relative  altitude,  range,  and  coarse  absolute  heading  of  the  encounter 
aircraft.  The  clock  bearing  and  altitude  xone  methods  of  presenting  the  data 
were  chosen  to  permit  direct  implementation  of  light  rings  as  in  an  IPC  type 
display  [2],  The  fine  bearing  provides  more  sophisticated  displays  with  the 
greater  accuracy  required  for  numerical  or  graphic  displays,  particularly  if 
trail  information  on  a  CRT  is  desired.  Absolute  heading  is  presented  to  match 
normal  system  protocol;  relative  heading  for  graphic  displays  can  be  calculated 
by  subtraction  of  the  own  heading  provided  by  the  previous  data  set. 

The  Position  Data  Set  also  supplies  information  on  the  ATC  control  status 
and  ATARS  equipage  of  the  other  aircraft.  These  items  help  the  pilot  judge  who 
will  assume  control  of  resolving  the  conflict  and  aid  in  his  evaluation  of  the 
situation.  Finally,  an  indication  is  provided  as  to  whether  this  encounter  is 
the  most  critical  currently  existing  for  the  aircraft.  This  aids  simple 
avionics  in  choosing  the  encounter  to  display. 

4.1.3  Supplementary  Proximate  Data  (Figure  10) 

The  Supplementary  Proximate  Data  Set  provides  information  on  the  motion  of 
a  proximity  encounter  aircraft  whose  current  position  was  defined  in  the 
Position  Data  Set.  This  information  will  be  useful  for  sophisticated  ATARS 
users  in  two  ways:  it  will  permit  a  more  complete  graphic  specification,  and 
it  will  permit  accurate  positional  coasting  in  the  absence  of  new  data  link 
messages.  The  motion  quantities  provided  by  this  data  set  are  velocity,  turn 
type  indication,  and  vertical  speed.  In  addition,  a  finer  heading  and  an 
encounter  track  number  are  provided.  The  use  of  the  track  number  is  discussed 
in  section  4.2.1. 
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Clock  Bearing  (CB) 

Fine  Bearing  (FB) 
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Altitude  Zone 

Relative  Altitude  (RA) 

Range 

Coarse  Heading  (CH) 

ATC  Control 

ATARS  Equipped 
Host  Critical  Flag 

TOTAL 


Bits  Interpretation 

4  1  o'clock  (0001)  through  12 

o'clock  (1100) 

3  Bearing  to  target  = 

[(CB)  -  1/2]  x  30°  +  (FB) 
x  3.75° 

2  Bit  1:  Equal  or  above  (1)  or 

Below  (0) 

Bit  2:  Co-altitude  (0  to  500' ) 

(1)  or  Not  (600'  or  more) 

(0) 

3  If  Co-altitude:  100'  lsb 
If  Not  Co-altitude: 

200’  lsb  beyond  600' 

(thus  600'  to  2000') 

6  0.2  nm  lsb 

3  N(000),  NE(001),  thru  NW(lll) 

1  Controlled  (1)  or 

Not  Controlled  (0) 

1  ATARS  equipped  (1)  or  Not  (0) 

1  Most  critical  advisory  (1)  or 

Not  (0) 
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Fie.  9.  Position  Data 


Field 

Bits 

Interpretation 

Track  Number 

3 

0  through  7 

Fine  Heading  (FH) 

4 

Heading  of  target  = 

[ (CH)  -  1/2]  x  45°  +  (FH)  x 
2.8125°  [Note:  CH  is  contained 
in  position  data] 

Velocity 

7 

10  knot  lsb 

Turn  Type  of  Aircraft 

3 

Bit  1:  Turn  (1)  or  Straight  (0) 
Bit  2:  Right  (1)  or  Left  (0) 

Bit  3:  Strong  (1)  or  Weak  (0) 

Vertical  Speed  of  Aircraft 

6 

200  FPM  lsb  (Two's  Complement 
with  positive  upward) 

Spare 

1 

Set  to  Zero 

TOTAL 

24 

rig.  10.  Supplementary  Proximate  Data. 
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This  supplementary  information  is  transmitted  currently  only  when  24  bits 
are  available  in  an  existing  ATARS  message,  such  as  would  normally  be  the  case 
with  only  a  single  proximity  encounter  present.  However,  the  Full  Information 
protocol  described  in  the  previous  chapter  would  have  required  it  to  be  sent 
for  all  encounters. 

4.1.4  Start  Proximity  and  End  Encounter  Data  (Figure  11) 

The  Start  Proximity  and  End  Encounter  Data  Sets  are  actually  alternate 
interpretations  of  the  same  data  set,  controlled  by  whether  the  first  bit  is 
set  to  'O'  or  *  1*  respectively.  Both  sets  are  intended  for  sophisticated  users 
only,  and  help  them  to  control  their  internal  encounter  file  records. 

The  Start  Proximity  Data  Set  signals  the  start  of  a  proximity  encounter 
and  supplies  the  track  number  assigned  to  it  by  the  ground.  Section  4.2.1 
describes  in  more  detail  the  use  of  this  number.  Also,  this  data  set  provides 
the  velocity  of  the  encounter  aircraft,  which  is  the  most  important  aircraft 
attribute  missing  from  the  Position  Data  Set.  Thus,  even  if  no  Supplementary 
Data  Set  is  ever  transmitted,  a  reasonably  accurate  value  of  velocity  will  be 
known.  Finally,  room  exists  for  aircraft  identification  data,  such  as  type  or 
size;  at  present,  this  field  Is  undefined. 

The  only  field  used  in  the  End  Encounter  Data  Set  is  the  track  number. 

When  this  set  is  received  by  a  sophisticated  user,  it  knows  to  cancel  the 
corresponding  encounter  file  and  remove  the  encounter,  proximity  or  threat, 
from  the  display.  This  set  is  given  lowest  priority,  since  sophisticated 
avionics  can  automatically  cancel  encounters  not  updated  from  the  ground. 

Also,  if  the  track  number  is  immediately  needed  by  the  ground  for  a  new 
encounter  (all  other  numbers  being  active),  the  data  set  is  not  employed. 
Instead,  a  start  message  with  the  track  number  is  sent  for  the  new  encounter; 
the  avionics,  recognizing  this  number  reuse,  will  perform  as  if  the  end  message 
had  been  generated. 

4.1.5  Basic  Threat  Data  (Figure  12) 

By  definition,  a  threat  encounter  is  more  critical  than  a  proximity 
encounter.  Thus,  the  Basic  Threat  Data  Set  has  been  provided  to  supply  the 
additional  information  required  for  accurate  threat  evaluation  and  assessment. 
This  information  is  of  three  types:  mute  exact  current  position,  aircraft 
motion,  and  predicted  miss  distance. 

Four  of  the  fields  in  this  data  set,  namely  fine  heading,  turn  type 
indication,  vertical  speed,  and  track  number,  were  also  present  in  the 
Supplementary  Proximate  Data  Set.  As  discussed  there,  they  provide  a  more 
complete  description  of  the  aircraft's  current  state  of  motion  and  permit 
coasting  the  display  in  the  absence  of  uplink  messages.  In  addition  though,  in 
conjunction  with  the  horizontal  miss  distance  field,  they  permit  the  complete 
calculation  of  the  time  and  location  of  the  closest  point  of  approach  of  the 
threat  aircraft  by  sophisticated  onboard  computers  (see  the  Appendix). 
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Start  Proximity: 


Field  3 its 
Sensor  Termination  1 
Velocity  7 
Track  Number  3 
Aircraft  Abbreviated  Data  13 

TOTAL  24 


End  Encounter: 

Field  Bits 

Sensor  Termination  1 

Spare  7 

Track  Number  3 

Spare  13 

TOTAL  24 


Fig.  11.  Start  Proximity  and  End 


Interpretation 

Set  to  0 
10  knot  lsb 
0  through  7 
Currently  undefined 


Interpretation 

Set  to  1 
Not  used 
0  through  7 
Not  used 


Encounter  Data  Sets. 


28 


Field 

Bits 

Interpretation 

Horizontal  Miss  Distance 

3 

0.2  nm  lsb 

Vertical  Speed  of  Threat 

6 

200  FPM  lsb  (Two’s  complement 
with  positive  upward) 

Relative  Altitude  Extension 
(RAE) 

3 

500’  lsb 

RAE  is  added  to  the  2000’ 
relative  altitude  provided 
by  RA  in  position  data  (Fig.  9) 
[If  RA  <  2000’,  RAE=0] 

Fine  Heading  (FH) 

4 

Heading  of  threat  =  [(CH)  -  1/2] 
x  45°  +  (FH)  x  2.8125°  [Note:  CH 
contained  in  position  data 

(Fig.  9)] 

Turn  Type  of  Threat 

3 

Bit  Is  Turn  (1)  or  Straight  (0) 
Bit  2:  Right  (1)  or  Left  (0) 

Bit  3:  Strong  (1)  or  Weak  (0) 

Track  Number 

3 

0  through  7 

First  Time  Threat  Data 
Transmitted 

1 

First  time  (1)  or  Not  (0) 

Commanded  Bit 

1 

Threat  is  receiving  resolution 
advisory  (1)  or  Not  (0) 

TOTAL 


24 


Fig.  12.  Basic  Threat  Data 


Even  unsophisticated  users  can  make  threat  assessments  from  this  data  set 
as  the  miss  distance  by  itself  indicates  the  severity  of  the  threat  and  hence 
the  need  for  action.  Also,  the  commanded  bit  informs  the  pilot  whether  the 
other  pilot  is  receiving  an  ATARS  resolution  advisory  coordinated  with  his,  and 
thus  whether  or  not  they  will  be  acting  in  concert  to  avoid  a  collision. 
Finally,  the  first  time  threat  data  transmitted  bit  can  be  tied  to  an  audible 
alarm  to  announce  the  start  of  the  threatening  situation. 

Threatening  aircraft  can  be  more  than  2000  feet  in  altitude  from  the 
subject  aircraft  if  either  or  both  have  large  altitude  rates.  Thus  this  data 
set  also  provides  an  altitude  extension  field  which,  combined  with  the  Position 
Data  Set  field,  permits  altitude  differences  as  much  as  5500  feet  to  be 
represented. 


4.1.6  Start  Threat  Data  (Figure  13) 

The  Start  Threat  Data  Set,  transmitted  on  the  first  scan  on  which  a  threat 
situation  exists,  is  identical  except  for  the  first  bit  in  both  format  and 
interpretation  to  the  Start  Proximity  Data  Set.  This  first  bit  specifies 
whether  a  new  encounter  has  arisen  or  whether  an  existing  proximity  encounter 
has  now  transitioned  to  threat  status.  In  the  latter  case,  the  information  in 
this  data  set  was  already  provided  by  the  Start  Proximity  Message.  Thus,  if  no 
changes  have  occurred  (particularly  in  velocity),  this  data  set  can  be 
omitted. 


4.1.7  Resolution  Data*  (Figure  14) 

The  Resolution  Data  Set  is  used  to  convey  the  ATARS  resolution  advisories 
to  the  aircraft.  This  data  set  is  necessary  for  ATARS  only  until  the 
ATARS/BCAS  interface  protocol  becomes  operational  and  the  Resolution  Advisory 
Register  (RAR)  is  implemented.  At  that  time,  a  separate  set  of  RAR  messages 
will  be  used  to  transmit  the  resolution  advisories. 

The  first  11  bits  of  the  data  set  present  the  set  of  resolution  advisories 
for  the  aircraft.  Any  '1'  among  the  first  8  bits  indicates  the  existence  of 
the  corresponding  advisory.  Thus,  for  example,  10000010  is  decoded  as  turn 
right  and  don’t  climb.  The  last  3  bits,  taken  as  a  group,  specify  a  single 
vertical  speed  limit  advisory  as  defined  in  the  figure. 

The  first  time  transmitted  bit  is  set  whenever  the  resolution  state 
changes,  either  due  to  the  addition  or  subtraction  of  an  advisory.  This  bit  is 
intended  to  actuate  an  audible  alarm  to  alert  the  pilot  of  the  change. 

Finally,  the  track  number  is  used  to  indicate  the  encounter  that  has 
necessitated  the  advisories.  If  multiple  encounters  are  involved,  one  at  random 
will  be  chosen  for  this  field. 


*The  addition  of  the  Resolution  Advisory  Register  to  coordinate  BCAS  and  ATARS 
activities  will  require  the  message  to  be  redefined.  It  is  included  here  for 
completeness  since' it  was  used  in  the  initial  ATARS  test  system. 
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Field 

Bits 

Interpretation 

Continuation 

1 

(1)  Track  Number  Exists  from 
Previous  Proximity  State 
(0)  New  Encounter 

Velocity 

7 

10  knot  lsb 

Track  Number 

3 

0  through  7 

Aircraft  Abbreviated  Data 

13 

Currently  undefined 

TOTAL 

24 

Fig.  13.  Start  Threat  Data. 
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Field 


Bits 


Interpretation 


Resolution  Advisory 
First  Time  Transmitted 
Track  Number 
Spares 


11  See  Below 

1  First  Time  (1)  or  Not  (0) 

3  0  through  7 

9  Not  used 


TOTAL 


24 


Bit  position  in 
11-bit  field 


Advisory  Implied 
when  set 


1 

2 

3 

4 


Turn  right 
Turn  left 
Climb 
Descend 


5 

6 

7 

8 


Don't  turn  right 
Don't  turn  left 
Don’t  climb 
Don't  descend 


Bits  9,  10,  11  Advisory  Implied 

of  11-bit  field 


000 


No  VSL 


001 

010 

011 


Limit  climb  to  500 
feet  per  minute  (FPM) 
Limit  climb  to  1000  FPM 
Limit  climb  to  2000  FPM 


100 

101 

110 


Limit  descent  to  500  FPM 
Limit  descent  to  1000  FPM 
Limit  descent  to  2000  FPM 


Fig.  14.  Resolution  Data. 
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4.2  ATARS  Message  Combinations 


It  is  possible  to  create  a  large  number  of  ATARS  COMM-A  messages  by 
combining  various  pairs  of  the  data  sets  just  described.  This  section 
describes  the  pairings  presently  defined  and  under  test  in  the  first  phase 
ATARS  system.  Figure  15  lists  these  messages  along  with  the  A-Definition 
Subfield  (ADS)  code  for  each  COMM-A  message  [5].  Only  eight  ADS  codes  are 
currently  in  use  for  ATARS  (although  more  are  available),  so  some  sharing  of 
codes  between  different  messages  was  required.  In  each  such  case,  chough,  a 
bit  within  the  message  field  differentiates  between  the  alternatives.  In 
particular,  the  first  message  bit  in  an  ADS  23  message  differentiates  26q  and 
26^  messages,  while  the  last  bit  in  an  ADS  31  message  serves  to  differentiate 
31g  from  31j_. 

4.2.1  Onboard  Tracking 

All  ATARS  messages  other  than  the  own  message  are  employed  only  when  an 
encounter  exists.  When  the  ground  determiner,  that  a  new  encounter  has 
commenced,  it  assigns  a  track  number  to  it  which  is  maintained  throughout  its 
duration.  A  sophisticated  user  could  use  this  track  number  in  every  message  so 
that  messages  can  be  correlated  from  scan  to  scan  and  used  to  maintain  an 
onboard  encounter  file.  However,  since  unsophisticated  users  do  n«t  require 
track  numbers  for  proper  operation  of  their  displays,  the  track  number  is  not 
part  of  the  essential  data  base  for  an  encounter,  and  thus  is  not  included  in 
the  Position  Data  Set. 

A  sophisticated  user,  however,  can  still  maintain  track  identity.  The 
first  message  transmitted  for  any  encounter  contains  a  Start  Data  Set.  Since 
this  set  contains  a  track  number,  the  user  will  be  able  to  initiate  a  file. 
Also,  the  last  message  sent  for  any  encounter  contains  the  End  Data  Set,  which 
also  has  the  track  number.  Thus,  the  user  will  know  when  to  terminate  an 
encounter  file.  Whenever  the  encounter  is  a  threat,  the  Basic  Threat  Data  Set, 
with  track  number,  is  transmitted  each  scan.  Finally,  whenever  the  encounter 
is  the  only  proximity  existing,  and  for  some  multiple  proximity  situations,  the 
single  proximity  message  will  be  employed  for  the  encounter,  and  it  contains 
the  track  number.  Thus,  only  in  the  case  that  the  user  receives  a  dual 
proximity  message  will  the  track  number  not  be  supplied.  By  correlating  on 
position  with  the  active  encounter  files,  proper  assignment  of  the  two 
proximity  messages  can  be  made. 

4.2.2  Own  Messages  (ADS  24,  25,  or  31q) 

The  own  data  is  employed  by  sophisticated  users  for  various  onboard 
calculations  as  described  earlier.  Thus  an  own  message  is  required  whenever 
any  of  the  following  conditions  apply: 
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Message 

ADS 

Data  Set  1 

Data  Set  2 

Own 

24 

Own 

- 

Own  Plus  Proximity 

25 

Position 

Own 

Start  Proximity 

26o 

Start  Proximity 

Position 

End  Encounter 

261 

End  Encounter 

Position 

Dual  Proximity 

27 

Position 

Position 

Single  Proximity 

28 

Position 

Suppl.  Proximate 

Start  Threat 

29 

Start  Threat 

Own 

Threat 

30 

Basic  Threat 

Position 

Own  Plus  Supplementary 

310 

Own 

Suppl.  Proximate 

Resolution 

3lj* 

Resolution 

last  bit  =  1 

*THE  RAR  WILL  USE 

A  DIFFERENT 

ADS  FOR  RESOLUTION 

ADVISORIES. 

Fig.  15.  ATARS  Message  Definitions. 
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1.  tue  seam  condition  has  changed 

2.  the  own  heading  or  own  velocity  being  employed  onboard 
differs  from  the  current  ground  value  by  more  than  a 
parametric  value 

These  conditions  insure  accurate  data  is  available  to  sophisticated  users. 

It  should  be  noted  that  the  Own  Data  Set  contains  a  heading  turn  rate 
field.  Thus,  the  onboard  computer  can  track  through  a  constant  turn  without 
ground  suppoi . ;  only  messages  at  the  start  and  end  of  turns  are  required.  In 
fact,  the  reason  for  including  the  turn  rate  field  was  just  to  reduce  the 
number  of  own  messages  that  would  be  needed  solely  for  new  heading 
information. 

Since  only  24  bits  of  own  data  exist,  the  remaining  24  COMM-A  bits  are 
free  for  other  use.  Three  own  messages  are  defined,  as  shown  in  Figure  15,  in 
which  these  bits  are  used  for  proximity  position  data  (ADS  25),  supplementary 
proximate  data  (ADS  31q),  or  left  blank  (ADS  24).  The  rules  for  which  one  to 
employ  are  provided  in  the  next  section. 

Any  proximity  encounter  can  be  joined  with  the  own  data  in  the  first  case, 
but  the  supplementary  proximate  data  in  the  second  case  must  be  that  of  the 
most  critical  encounter.  With  this  stipulation,  the  onboard  avionics  will  know 
which  position  data  set  to  join  with  this  supplementary  data.  As  a  result  of 
this  rule,  though,  the  own  plus  supplementary  message  can  never  be  employed 
when  a  threat  exists,  as  then  no  proximity  encounter  will  be  most  critical. 

4.2.3  Proximity  Messages  (ADS  25,  26q,  26^,  27,  28) 

Every  proximity  encounter  is  begun  with  a  start  proximity  message  (ADS 
26q)  so  that  sophisticated  users  wiil  receive  the  data  required  for  initiating 
an  encounter  file.  This  message  also  includes  the  position  data  for  this  first 
scan.  Then,  once  the  encounter  geometry  no  longer  exists,  an  end  encounter 
message  (ADS  26^)  is  transmitted  so  that  sophisticated  users  will  know  to 
terminate  the  file.  The  position  data  in  this  message  is  identical  to  that 
sene  the  previous  scan,  so  that  positional  correlation  can  be  performed  when 
multiple  encounters  wit^  the  same  track  number  exist  (as  can  be  caused  by 
multiple  sensor  uplink  scenarios). 

After  the  initial  scan,  a  position  data  set  is  transmitted  once  per  scan 
for  a  proximity  encounter.  If  multiple  proximities  exist  on  any  scan,  two  such 
sets  at  a  time  are  sent  via  dual  proximity  messages  (ADS  27).  If  only  one 
proximity  exists,  or  if  one  is  left  after  the  dual  messages,  it  is  sent  as 


either  an  own  plus  proximity  message  (ADS  25)  or  a  single  proximity  message 
(ADS  28).  The  former  message  is  employed  if  an  own  data  set  is  required  on  the 
scan,  the  latter  otherwise.  Thus  .  :he  supplementary  proximate  data,  which  is 
the  other  half  of  the  single  pro?  <ity  message,  is  transmitted  only  when  no 
other  data  set  is  required  and  2*.  bits  are  unused.  Fortunately  for 
sophisticated  users,  this  will  be  the  normal  case  when  only  one  proximity 
encounter  exists  for  the  subject  aircraft.  Unsophisticated  users  receiving  the 
single  proximity  message  will  simply  ignore  the  second  24  bits.  A  complete 
flow  chart  of  proximity  message  selection  rules  is  provided  in  the  next 
section. 


4.2.4  Threat  Messages  (ADS  26^,  29,  30) 

A  threat  message  (ADS  30),  consisting  of  a  position  and  a  basic  threat 
data  set,  is  transmitted  every  scan  on  which  a  threat  encounter  exists.  In 
addition,  a  start  threat  message  (ADS  29),  containing  start  and  own  data  sets, 
may  be  required  on  the  initial  scan  of  a  threat.  This  message  is  always 
required  if  the  encounter  begins  in  the  threat  state,  but  is  only  required  for 
an  encounter  transitioning  from  a  proximity  to  a  threat  if  it  supplies  updated 
information  required  by  onboard  avionics  for  coasting  or  closest  point  of 
approach  calculations.  That  is,  it  is  sent  if: 

1.  an  own  data  set  were  required  in  any  event  on  that  scan  for 
a  reason  given  in  4.2.2 

2.  the  last  reported  velocity  for  the  encounter  (via  a  proximity 
start  or  supplementary  proximate  data  set)  is  no  longer  accurate 
in  either  a  percentage  or  absolute  sense. 

Finally,  if  .  threat  encounter  ends,  without  reverting  to  a  proximity,  an 
end  encounter  message  (ADS  26^)  is  sent.  Its  format  is  as  described  in  the 
previous  section. 


4.2.5  Resolution  Message  (ADS  31^) 

The  resolution  message  is  transmitted  once  each  scan  to  an  aircraft  as 
long  as  one  or  more  resolution  advisory  exists  for  it.  In  addition,  one  final 
null  resolution  message  is  sent  when  the  last  resolution  advisory  has  been 
terminated  so  the  onboard  avionics  will  know  to  cancel  its  resolution  display; 
otherwise  it  would  have  to  wait  until  a  resolution  timeout  period  expired. 

This  message  is  temporary,  to  be  employed  only  until  the  RAR  is 
operational.  Thus,  no  second  data  set  has  been  defined  for  the  second  24  bits. 
Instead,  they  are  all  set  to  zero  except  for  the  final  one;  this  permits  the 
resolution  message  (ADS  31^)  to  be  differentiated  from  the  own  plus 
supplementary  message  (ADS  31g). 
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Since  this  message  is  temporary,  no  provision  has  been  made  for  multisite 
resolution  logic.  That  is,  each  resolution  message  is  taken  to  present  the 
entire  active  set  of  resolution  advisories.  Thus,  if  such  messages  are  sent 
from  two  or  more  sites,  each  message  must  include  the  resolution  advisories 
being  issued  by  the  other  sites  or  it  will  cause  those  resolution  advisories  to 
be  erased. 


4.3  Message  Transmission  Rules 

The  previous  section  has  listed  the  various  ATARS  messages  available  for 
transmitting  information  to  the  aircraft.  In  several  instances,  particularly 
with  respect  to  own  and  proximity  data,  choices  of  message  exist.  This  section 
will  describe  how  encounter  status,  information  already  available  on  board,  and 
presence  of  other  encounters  define  the  rules  for  message  selection.  Figure  16 
provides  the  overall  flowchart  for  this  selection  process. 

Besides  specifying  which  messages  to  employ  on  a  scan,  this  flowchart  also 
defines  the  order  in  which  the  ATARS  messages  are  to  be  transmitted.  Ordering 
is  important  because  of  the  DABS  Comm-A  message  protocol  for  the  data  link.  In 
particular,  ATARS  messages  that  fail  to  be  transmitted  due  to  infrequent  lack 
of  link  time  will  be  discarded. 

Two  classes  of  data  link  messages  are  defined  by  DABS:  priority  and 
non-priority.  Messages  of  the  former  class  are  always  transmitted  before  those 
of  the  latter  class.  Within  each  class,  messages  are  transmitted  by  a 
first-in-first-out  protocol.  Thus  it  is  the  responsibility  of  ATARS  to  list 
its  messages  in  order  of  importance. 

Referring  to  the  flowchart,  it  is  seen  that  the  two  priority  messages, 
resolution  and  threat,  are  put  at  the  head  of  the  list  whenever  required.  The 
resolution  message,  presenting  the  resolution  advisory  or  set  of  advisories,  is 
the  most  Important.  It  is  used  during  a  serious  threat  situation,  and  also  on 
the  first  scan  after  encounter  resolution  to  terminate  the  advisories.  One 
threat  message  is  required  per  threat  encounter  existing  for  the  scan.  These 
messages  are  ordered  as  described  in  Section  2.2. 

If  a  threat  encounter  starts  in  that  state,  a  start  threat  message  is 
required  on  the  first  scan  in  addition  to  the  threat  message,  however,  if  the 
encounter  has  transitioned  from  proximity  to  threat  status,  this  message  may  or 
may  not  be  required;  Section  4.2.4  described  the  criteria  for  this  choice. 

Since  the  threat  start  message  is  non-priority,  it  might  nor  be  ‘vnnsnitted  due 
to  the  presence  of  too  many  priority  messages.  In  that  event,  i;.  i  .'j*'  be 
re-formatted  and  placed  on  the  ATARS  list  on  the  next  scan  an  Mi  •:  ransui-  tfced  to 
and  acknowledged  by  the  aircraft. 

After  all  threat  encounters  have  been  considered,  the  messages  for  the 
proximity  encounters  (if  any)  are  created  and  placed  on  the  list.  The  second 
page  of  the  flowchart  details  the  applicable  logic.  First  the  newly  begun 
proximity  encounters  are  handled  in  order  of  rank,  with  a  start  proximity 
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Best  Available  Copy 


New 

Scan 


DONE 


Fig.  16.  Ordering  of  ATARS  Messages  (1  of  2). 
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Fig.  16.  Ordering  of  ATARS  Messages  (2  of  2). 
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message  created  for  each.  As  with  start  threat  messages,  the  start  proximity 
messages  must  be  re-created  each  scan  until  successfully  received  by  the 
aircraft.  Then  the  proximity  encounters  continuing  from  previous  scans  are 
processed. 

The  main  message  for  presenting  proximity  encounter  position  data  is  the 
dual  proximity,  which  provides  that  data  for  two  separate  encounters.  As  long 
as  two  or  more  proximity  encounters  remain  to  be  processed,  the  highest  ranking 
two  of  them,  as  defined  in  Section  2.2,  are  used  to  construct  such  a  message. 
Should  only  one  proximity  encounter  remain,  its  data  is  placed  into  either  an 
own  plus  proximity  message  or  a  single  proximity  message.  The  former  message 
is  employed  whenever  own  data  is  required  on  the  scan  for  a  reason  described  in 
Section  4.2.2.  If  that  data  is  not  required,  or  has  already  been  sent  via  a 
start  threat  message,  a  single  proximity  message  is  used  in  which  the  remaining 
24  message  bits  are  used  to  transmit  supplementary  proximate  data  for  the 
encounter.  Thus  this  added  data  is  only  sent  for  the  least  important 
proximity.  However,  since  proximity  rankings  will  vary  from  scan  to  scan,  the 
data  should  periodically  appear  for  all  encounters. 

If  all  proximity  position  data  is  handled  by  dual  proximity  messages,  and 
own  data  is  required  on  the  scan,  one  of  two  message  types  may  be  applicable. 

If  no  threat  encounters  exist,  the  own  plus  supplementary  message  is  employed, 
with  the  supplementary  data  being  that  of  the  proximity  encounter  labelled  most 
critical.  Otherwise,  if  a  threat  exists  and  hence  no  proximity  can  be  most 
critical,  a  simple  own  message  is  employed.  Also,  if  only  threat  encounters 
exist,  with  no  proximity,  the  simple  own  message  is  used  for  own  data  when 
required. 

Finally,  if  an  encounter  has  terminated  on  the  current  scan,  an  end 
message  is  created  for  it.  This  message  is  cancelled,  however,  if  that 
encounter  track  number  has  already  been  assigned  to  another  active  encounter  as 
discussed  in  Section  4.1.4. 

4.4  Alternative  Messages  not  Selected  for  Implementation 

This  section  describes  modifications  and  additions  to  the  ATARS  message 
set  described  in  section  4.2  that  might  prove  useful  in  future  ATARS  systems. 
None  of  these  features  are  currently  under  consideration. 

4.4.1  Aircraft  Information  Messages 

At  present,  there  are  13  bits  reserved  in  the  start  threat  and  start 
proximity  messages  for  aircraft  identification  data.  These  data  fields  have 
been  left  undefined  for  now  as  no  such  information  is  available  in  the  ground 
sensor.  However,  once  such  information  is  provided,  it  may  well  require 
more  than  13  bits  for  its  presentation. 
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A  complete  aircraft  specification  could  include  the  airline  or  operator  of 
the  encounter  aircraft  (such  as  Eastern  Airlines),  its  flight  number  (such  as 
137),  and  the  type  of  aircraft  (such  as  jumbo  or  light  twin).  This  description 
would  help  the  pilot  visually  acquire  the  aircraft  and  allow  him  to  listen  to 
ATC  voice  messages  sent  to  it.  Although  the  DABS  sensor  does  not  contain  these 
items  of  information,  a  combination  of  DABS  transponder  flight  number  readout 
and  access  to  flight  plan  data  over  the  existing  DABS-ATC  ground  link  could 
easily  provide  them. 

Any  th~ee  digit  flight  number  could  be  represented  by  a  10  bit  field  (2*0 
=  1024).  There  are  two  contrasting  methods  for  representing  the  airline  and 
type  data,  however.  The  one  requiring  the  fewest  bits  is  table  lookup.  With 
this  scheme,  all  airlines  and  operators  are  assigned  a  number  (such  as  1  = 
Eastern  Airlines,  2  =  Wiggins  Airways,  etc.),  as  are  all  possible  types  of 
aircraft.  Then,  for  example,  if  7  bits  and  4  bits,  respectively,  are  used  for 
the  data  fields,  128  airlines  or  operators  and  16  types  of  aircraft  could  be 
represented.  The  onboard  computer  would  have  the  two  decoding  tables  in  its 
memory,  and  would  thus  be  able  to  read  the  field  values  and  provide  the  display 
with  the  proper  character  strings  (EA,  JUMBO,  etc). 

The  main  drawback  of  this  scheme  is  the  difficulty  caused  by  growth.  Each 
time  a  new  airline  or  aircraft  type  was  required  to  be  added  to  the  system,  a 
new  lookup  table  would  have  to  be  constructed.  Then  every  aircraft  that  wanted 
to  stay  current  would  require  an  avionics  upgrade. 

A  more  direct  approach,  but  one  that  requires  more  bits  to  implement,  is 
the  straightforward  encoding  of  the  character  strings  themselves.  Any  letter 
can  be  denoted  by  a  5  bit  number:  A=l,  B=2,  ...,  Z=26.  Thus,  if  every  airline 
or  operator  could  be  identified  by  being  assigned  a  two  letter  code  (EA=Eastern 
Airlines),  and  every  type  of  aircraft  was  readably  abbreviated  by  three  letters 
(JMB=jumbo,  LTW=light  twin),  10  bit  and  15  bit  message  fields  respectively 
would  be  required.  The  onboard  computer  in  this  scheme  would  simply  read  the 
character  string  and  present  it  for  display.  Growth  would  be  transparent  to 
the  avionics,  as  new  character  strings  would  be  read  as  easily  as  old  ones. 

With  this  approach,  the  three  aircraft  information  fields  would  require  a 
total  of  35  bits.  Figure  17  illustrates  how  a  new  start  threat  message  could 
be  formatted  to  accommodate  these  lengths.  Since  Ihe  own  data  no  longer 
appears  in  this  message,  it  would  require  another  message  for  its  transmission. 
However,  new  own  data  is  often  not  required  when  a  threat  encounter  begins. 
Also,  extra  bits  for  its  transmission  may  already  exist,  such  as  in  an  own  plus 
proximity  form.  Thus,  few  additional  own  messages  should  be  produced  as  a 
result  of  this  message  char:  e. 

A  proximity  encounter  would  probably  not  require  as  full  an  aircraft 
specification.  If  only  the  most  important  field  were  sent,  namely  the  aircraft 
type,  the  proximity  start  data  set  depicted  in  Figure  18  would  suffice.  The 
loss  of  the  start/end  differentiation  bit  (see  Figure  11)  could  be  overcome  by 
using  different  ADS  values  for  start  and  end  messages,  while  the  coarser 
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Field 

Bits 

Interpretation 

Continuation 

1 

(1)  Track  Number  Exists 
Previous  Proximity 
(0)  Hew  Encounter 

Velocity 

7 

10  knot  lsb 

Track  Number 

3 

0  through  7 

Aircraft  Type 

15 

3  letters,  5  bits  each 

Airline/Operator 

10 

2  letters,  5  bits  each 

Flight  Number 

10 

3  digit  integer 

Spare 

2 

- 

TOTAL 

48 

Fig.  17.  Revised  Start  Threat  Message 


Field 


Bits 


Interpretation 


Velocity 
Track  Number 
Aircraft  Type 


m 


"Si 


v- 


6  20  knot  lsb 

3  0  through  7 

15  3  letters,  5  bits  each 


TOTAL 


24 


Fig.  18.  Revised  Start  Proximity  Data  Set. 
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velocity  value  resulting  from  the  loss  of  one  bit  in  its  field  would  still 
probably  prove  adequate.  Since  the  proposed  threat  start  message  contains 
aircraft  information  not  present  in  this  proximity  start  set,  it  would  now  have 
to  be  transmitted  every  time  a  proximity  encounter  transitioned  to  a  threat. 

If  longer  airline  flight  ID’s  are  introduced,  such  as  three  letter  and  4 
number  designations,  the  proposed  fields  would  no  longer  suffice.  In  that 
case,  a  separate  message  for  aircraft  information  would  be  required. 

4.4.2  Supplementary  Threat  Message 

Chapter  3  has  discussed  tne  possibility  of  providing  more  complete  threat 
encounter  data  to  sophisticated  users  if  different  classes  of  ATARS  users  are 
defined.  Also,  a  complete  closest  point  of  approach  (CPA)  specification  may  be 
required  for  all  users  if  the  calculations  presented  in  tne  Appendix  prove  to 
provide  unworkable  results  due  to  the  quality  and  accuracy  of  the  available 
uplinked  data.  Thus,  Figure  19  is  provided  to  suggest  a  possible  supplementary 
threat  message  that  would  serve  either  function. 

The  first  field  provides  the  threat  velocity  data  that  is  missing  from  the 
basic  threat  message.  Then  the  next  five  fields  supply  the  closest  point  cf 
approach  time  and  location  quantities  that  presently  require  onboard 
calculation.  The  track  number,  also  present  in  the  basic  threat  message, 
permits  a  means  to  correlate  basic  and  supplementary  threat  messages  for  an 
encounter  whenever  two  or  more  threats  exist.  Finally,  the  own  heading  and  own 
velocity  fields  have  been  placed  in  the  available  remaining  message  bits  to 
eliminate  the  need  for  separate  own  messages  during  the  time  a  threat  encounter 
exists. 


4.4.3  Generalized  End/Handoff  Data  Set 

The  currently  defined  end  encounter  message  (refer  to  Figures  11  and  15) 
wastes  a  large  number  of  bits.  First,  only  the  3  bit  track  number  is  used  in 
the  End  Encounter  Data  Set;  second,  a  full  Position  Data  Set  is  not  required 
for  onboard  correlation  when  the  identity  of  the  encounter  being  terminated  is 
in  doubt.  Thus,  this  entire  message  can  be  reduced  well  below  the  24  bit  data 
set  size. 

The  present  thinking  concerning  handoffs  of  threat  encounters  is  that  both 
the  old  and  the  new  sensor  will  employ  the  same  track  number,  and  thus  no 
onboard  notification  of  handoff  actions  is  required.  However,  when  site 
identification  bits  are  added  to  the  ATARS  COMM-A  messages,  a  sophisticated 
user  will  be  able  to  detect  the  change  of  sensor  for  the  track  number  being 
handed  off.  He  will  then  not  be  certain  whether  a  handoff  has  actually 
occurred,  or  whether  the  second  sensor  is  independently  reporting  on  a  separate 
encounter  and  coincidentally  using  that  same  track  number.  As  stated  earlier, 
various  unusual  or  error  conditions  can  result  in  such  multiple  sensor 
reporting  of  encounters. 
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1  WWn4  ili'ii  dwV  i 


Field 

Bits 

Interpretation 

Velocity 

7 

10  knot  lsb 

Time  to  CPA 

6 

1  second  lsb 

Altitude  Zone  at  CPA 

2 

see  Fig.  9 

Relative  Altitude  at  CPA 

3 

see  Fig.  9 

Clock  Bearing  at  CPA 

4 

see  Fig.  9 

Fine  Bearing  at  CPA 

3 

see  Fig.  9 

Track  Number 

3 

0  through  7 

Own  Heading 

7 

see  Fig.  8 

Own  Speed 

7 

see  Fig.  8 

Spare 

6 

- 

TOTAL 

48 

Fig,  19.  Possible  Supplementary  Threat  Message 


To  prevent  such  confusion,  use  of  a  handoff  message  is  proposed.  As 
illustrated  in  Figure  20,  a  combined  End/Handoff  Data  Set  has  been  defined;  the 
first  bit  differentiates  handoff  from  end  situations.  In  the  former  case,  the 
new  sensor's  track  number  and  that  of  the  previous  sensor  are  provided. 

Allowing  this  number  to  differ  may  be  necessary  if  future  more  complex  handoff 
protocols  are  introduced.  A  velocity  field  is  also  provided  in  the  not 
unlikely  event  the  new  sensor's  tracker  has  determined  a  different  value  from 
that  of  the  old  tracker. 

Used  to  end  an  encounter,  the  track  number  field  specifies  the  one  being 
terminated.  In  case  of  doubt  caused  by  multiple  track  number  use,  the  few 
position  fields  provided  are  more  than  sufficient  to  choose  the  applicable 
encounter  through  correlation.  The  new  position  set  format  is  acceptable  as 
only  sophisticated  users  will  be  interested  in  the  message.  Finally,  the  last 
bit  permits  an  end  message  to  be  transmitted  even  when  the  track  number  is 
already  being  reused  for  a  new  encounter.  This  simplifies  the  onboard  logic. 
Since  this  new  end  message  is  only  24  bits,  two  per  COMM-A,  or  one  with  an  own 
message  or  position  message,  is  possible. 
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Handoff : 


Field 

Bits 

Interpretation 

Termination 

1 

Set  to  0 

New  Track  Number 

3 

0  through  7,  new  sensor 

Old  Track  Number 

3 

0  through  7,  previous  sensor 

Velocity 

7 

10  knot  lsb 

Spare 

10 

- 

TOTAL 

24 

End  Encounter: 

Field 

Bits 

Interpretation 

Termination 

1 

Set  to  1 

Track  Number 

3 

0  through  7 

Clock  Bearing 

4 

see  Fig.  9 

Fine  Bearing 

3 

see  Fig.  9 

Altitude  Zone 

2 

see  Fig.  9 

Relative  Altitude 

3 

see  Fig.  9 

Range 

6 

see  Fig.  9 

Track  Reuse 

1 

(1)  Track  Number  Being  Reused 
(0)  Track  Number  Terminated 

Spare 

1 

- 

TOTAL 

24 

Fig.  20. 

Proposed  End/Handoff  Data  Set. 

5.0  ALTERNATIVE  SYSTEMS 


As  might  be  expected,  the  system  described  here  is  not  the  only  method 
that  could  be  proposed  for  delivering  information  about  other  aircraft  to 
pilots.  In  particular,  three  decisions  that  were  made  were  to: 

1.  display  only  aircraft  that  are  threats  or  potential  threats, 
rather  than  all  aircraft  in  the  vicinity  as  in  a  CDTI  system 

2.  perform  tracking  on  the  ground  rather  than  in  the  aircraft 

3.  use  relative  rather  than  absolute  bearings  and  altitudes 

In  each  case,  as  explained  below,  onboard  hardware  simplicity  and  pilot  display 
clarity  were  factors  in  the  decision. 

It  might  appear  that  the  ATARS  traffic  advisory  service  is  a  subset  of 
CDTI,  and  would  not  be  required  if  the  latter  were  implemented.  However,  the 
desire  to  provide  altitude,  heading,  and  velocity  of  threat  aircraft  to  aid  in 
pilot  acquisition  and  avoidance  negates  this  assumption.  It  would  be 
impractical,  in  any  display  that  could  fit  in  a  cockpit,  to  provide  this  level 
of  data  on  any  sizeable  number  of  aircraft.  Also,  by  providing  data  only  when 
potential  threats  exist,  pilots  can  more  easily  notice  and  utilize  the  data. 
Thus,  CDTI  should  be  viewed  as  a  companion,  rather  than  competing,  service  to 
ATARS. 

The  ATARS  traffic  advisory  service,  as  viewed  herein,  sends  traffic 
advisory  messages  directly  addressed  to  each  aircraft  for  each  advisory.  An 
alternative  approach  would  be  to  use  a  broadcast  mode  of  data  link  messages. 

In  this  mode,  a  position  message  for  each  aircraft  would  be  broadcast  to  all 
listeners  once  per  scan.  The  onboard  equipment  would  then  filter  these 
messages  to  locate  all  potential  threats,  track  the  relevant  aircraft  via  the 
periodic  position  reports,  and  provide  its  own  traffic  advisory  service.  The 
major  drawback  of  such  an  approach  is  the  sophistication  level  of  onboard 
equipment  that  it  assumes.  In  addition,  the  character  of  the  sensor 
surveillance  error  ellipse  is  such  that  an  onboard  tracker  could  not  possibly 
be  as  accurate  as  a  ground-based  one.  Also  the  ground  tracker  would  have  an 
established  track  at  the  time  the  encounter  began,  while  the  onboard  one  would 
require  several  scans  for  initialization,  thereby  delaying  accurate  display 
presentation.  Finally,  the  presumed  advantage  of  the  broadcast  mode,  fewer 
uplink  messages,  is  largely  illusory.  Almost  all  of  the  time,  2  or  fewer 
advisories  will  exist  for  an  aircraft,  and  often  both  of  these  can  be  included 
in  the  single  "free"  COMM-A  that  is  part  of  a  DABS  surveillance  request. 

The  main  reason  for  selecting  relative  bearing  of  a  threat  aircraft  for 
display  is  the  belief  that  pilots  would  find  it  easier  to  visually  acquire  an 
aircraft  with  that  data  format.  The  main  drawback  of  this  approach  is  that  the 
relative  bearing  might  contain  a  bias  caused  by  the  ground  tracker  error  of  the 
subject  aircraft's  true  heading.  This  can  be  corrected  onboard  by  tying  the 
aircraft  instruments  into  ATARS  avionics. 


Although  ARINC  studies  [6]  have  shown  that  pilots  prefer  absolute  altitude 
on  their  display,  relative  altitude  was  chosen  for  ATARS  messages  because  this 
format  requires  many  fewer  bits  to  specify  and  permits  simpler  onboard 
displays.  Users  may  display  absolve  altitude  by  making  encoded  altitude  and 
altimeter  correction  available  to  the  ATARS  display.  This  makes  it  possible  to 
determine  corrected  own  altitude  which  when  added  to  the  relative  altitude  in 
the  ATARS  messages  gives  the  absolute  altitude  of  the  threat  and  proximate 
aircraft 


6.0  ATARS  AVIONICS 


The  messages  which  have  been  described  are  capable  of  supporting  a  wide 
range  of  onboard  equipment.  In  general,  two  pieces  of  hardware  are  required: 
a  processor  to  decode  the  messages,  and  a  display  to  present  the  proximity, 
threat,  and  resolution  data  to  the  pilot.  The  processor  can  be  as  simple  as  a 
few  hardwired  chips  of  logic  or  as  complex  as  a  full-scale  microcomputer 
system,  while  the  display  can  vary  from  a  set  of  lights  or  synthesized  voice, 
to  an  alphanumeric  display,  all  the  way  to  a  complete  graphics  system. 

This  chapter  describes  some  examples  of  both  unsophisticated  and 
sophisticated  onboard  display  systems  to  indicate  the  types  of  implementations 
that  can  be  supported  by  the  previously  defined  messages.  The  basic  means  of 
differentiating  between  the  two  user  classes  is  that  unsophisticated  users 
make  no  use  of  encounter  track  numbers,  while  sophisticated  users  maintain 
onboard  track  files  for  the  active  encounters.  Thus,  only  the  latter  user 
attempts  message-to-message  or  scan-to-scan  correlation. 

Of  course,  numerous  other  displays  than  those  presented  here,  for  both 
sophisticated  and  unsophisticated  users,  could  be  designed.  In  addition, 
numerous  variations  or  combinations  of  these  systems  are  possible.  Also,  joint 
displays  that  integrate  ATARS  with  other  aircraft  functions  may  be  desirable. 
The  intent  of  this  chapter  is  to  provide  representative  examples  over  a  wide 
spectrum.  Some  of  the  factors  expected  to  influence  actual  implementations 
are  cost,  avionics  technology,  cockpit  space,  and  usefulness  of  the  various 
pieces  of  uplinked  information. 

6.1  Common  Avionics  Requirements 


Several  onboard  avionics  requirements  are  common  to  all  display  systems, 
from  the  simplest  unsophisticated  one  to  the  complete  graphics  system.  First, 
any  ATARS  message  may  be  repeated  several  times  by  the  ground  if  proper 
downlink  acknowledgment  is  not  received.  Thus,  a  duplicate  message  removal 
capability  is  required.  Conversely,  any  ATARS  message  prepared  by  the  ground 
may  not  be  transmitted  if  data  link  time  is  not  available.  Thus,  provisions 
for  holding  or  coasting  an  advisory  are  required  to  bridge  scans  with  missing 
position  reports.  Also,  timeout  hardware  is  required  to  remove  outdated 
encounter  or  resolution  information  as  end  messages  may  be  missed.  Current 
thinking  is  that  encounters  should  be  coasted  one  scan  and  then  dropped  if  not 
updated,  while  resolution  advisories  should  be  held  for  16  seconds. 

All  avionics  processors  must  be  able  to  recognize  the  various  message  ADS 
codes  so  as  to  be  able  to  find  the  data  they  need.  However,  not  all  data  sets 
must  be  read.  For  the  simplest  display,  only  the  Position  and  Resolution  Data 
Sets  are  required.  Thus,  fairly  simple  processors  may  be  possible  in  the 


ATARS  avionics.  However,  as  microcomputer  costs  continue  to  drop,  it  may  well 
be  feasible  to  provide  the  same  processing  unit  for  any  display,  and  "plugging 
in"  of  different  display  units  could  be  achievable.  Then  "low  cost"  or  "high 
cost"  would  refer  only  to  the  display  technology  and  complexity  being 
utilized. 

6.2  Unsophisticated  Displays 

An  example  of  a  simple  display  is  an  upgraded  IPC  display,  as  depicted  in 
Figure  21.  The  IPC  studies  have  shown  that  range,  altitude,  and  heading  of  the 
threat  aircraft  are  necessary  for  rapid  pilot  acquisition  and  threat 
assessments  techniques.  Thus,  these  quantities  have  been  added  for  the  most 
critical  encounter  as  numeric  fields  in  the  center  of  the  display.  Also,  the 
control  and  ATARS  status  of  the  other  aircraft  are  noted  for  pilot 
information. 

The  Position  Data  Set,  which  is  provided  for  every  encounter,  proximity 
or  threat,  has  fields  for  bearing  clock  position  and  relative  altitude  zone. 
Thus  simple  direct  connections  to  the  light  circuitry  could  be  made.  If 
several  advisories  existed  at  the  same  time,  a  light  for  each,  non-flashing  or 
flashing  according  to  its  proximity  or  threat  status,  would  be  lit.  The 
resolution  display  area  would  be  activated  whenever  a  resolution  message  were 
received,  and  cancelled  upon  reception  of  the  null  resolution  message,  or  by  a 
timeout. 

The  data  for  the  inner  numeric  fields  would  be  copied  from  the 
corresponding  message  fields  every  time  a  Position  Data  Set  with  its  most 
critical  flag  set  were  received.  This  data  could  continually  update  one 
encounter,  or  change  from  one  to  another,  according  to  changing  threat 
situations.  The  light  corresponding  to  the  current  most  critical  encounter 
would  be  special  in  some  manner  (color,  shape,  etc.)  so  that  pilot  correlation 
would  be  possible.  If  no  message  were  received  for  several  scans,  the  data 
would  be  timed  out. 

This  avionics  would  only  need  the  ability  to  decode  the  Position  and 
Resolution  Data  Sets  to  obtain  all  its  information.  A  slightly  more  complete 
threat  encounter  representation,  displaying  an  up/down  arrow  for  vertical 
maneuver  and  a  numeric  miss  distance  field,  would  also  require  decoding  of  the 
Basic  Threat  Data  Set. 

A  simple  synthesized  voice  system  can  also  be  constructed  to  present 
ATARS  advisories.  Some  level  of  hardware  complexity  is  required  for  message 
filtering,  as  voice  channel  time  considerations  prevent  even  the  most  critical 
encounter  from  being  described  more  often  than  every  few  scans.  A  set  of 
sample  rules  for  selecting  an  advisory  might  be  as  follows: 

1.  always  present  the  new  resolution  advisory  as  soon  as  possible  after 
reception  of  a  resolution  message  with  the  first  time  transmitted 
bit  set  (unless  a  special  display  exists  for  resolution  advisories) 
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Situation: 

Threat  above  at  1  o'clock  (flashing) 
Proximity  co-alt  at  8  o’clock  (non-flashing) 

Resolution: 

Descend,  don’t  turn  left 


Fig.  21.  Upgraded  IPC  Pisplay 


2.  Insure  that  the  most  critical  message  information  is 
presented  every  n  scans  (n  a  parameter) 

3.  present  a  voice  report  whenever  a  new  threat  encounter  begins,  as 
signalled  by  a  threat  message  with  its  first  time  transmitted 
bit  set 

4.  time  permitting,  present  a  voice  report  each  time  a  start 
proximity  message  is  received 

5.  with  the  remaining  time  on  the  voice  channel,  periodically 
describe  the  non-most  critical  encounters  to  the  extent 
permitted  by  the  hardware  complexity. 

This  avionics  would  also  require  a  repeat  button  to  prevent  the  pilot  from 
missing  advisories  blocked  by  radio  communications. 

Another  system  that  might  be  employed  for  an  unsophisticated  user  is  the 
multiple  encounter  alphanumeric  display  illustrated  in  Figure  22.  As  shown, 
the  display  can  support  two  encounters;  other  numbers  of  lines  could  obviously 
be  provided.  One  of  the  encounters  shown  on  the  display  will  be  the  one 
flagged  as  most  critical,  while  the  other  could  either  be  selected  at  random 
to  provide  rotating  coverage  or  be  the  second  one  received  which,  by  the 
transmission  rules  presented  above,  will  be  the  second  most  important.  In  the 
former  case,  though,  threat  situations  must  be  given  priority  over 
proximities.  Any  resolution  messages  received  are  displayed  on  the  bottom 
line. 

The  final  example  of  an  unsophisticated  user  display  to  be  considered 
here  is  the  3"  CRT  currently  under  development  at  Lincoln.  A  sample  screen 
picture  is  shown  in  Figure  23.  All  encounters  located  within  the  screen's 
range  are  displayed  in  the  manner  suggested  by  the  figure:  proximities  with 
position  and  relative  altitude  zone  indications,  threats  with  current 
position,  numeric  relative  altitude,  and  60  second  relative  motion  projection. 
The  resolution  advisories  are  displayed  in  two  screen  areas  simultaneously  for 
emphasis  and  clarity. 

In  order  to  maintain  a  constant  scale  on  this  small  display  screen,  a 
fixed  display  cutoff  must  be  chosen  for  the  advisories.  A  reasonable  li.iiit  is 
4  miles,  as  this  distance  satisfies  three  key  criteria: 

1.  most  advisories,  for  most  aircraft,  fall  within  this  limit 

2.  it  is  unlikely  that  a  pilot  could  visually  acquire  an  aircraft 
further  away  than  this  distance 

3.  a  larger  limit  would  compress  the  screen  so  much  that  pilot 
readability  for  critical  close-in  encounters  would  be  com¬ 
promised. 
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TRAFFIC  ADVISORIES 


TYPE 

BEARING 

(O'CLOCK) 

ALT 

(100  FT) 

RANGE 
(N  MI) 

COURSE 

STATUS 

THT 

10 

+06 

2.8 

SE 

E/C 

PROX 

_3 

-02 

5.1 

N 

U/N 

RESOLUTION  ADVISORY 
CLIMB  TURN  RIGHT 


Status: 

ATARS:  Equipped  (E)  or  Unequipped  (U) 

Rules:  Controlled  (C)  or  Not  Controlled  (N) 


Fig.  22.  Multiple  Encounter  Alphanumeric  Display 


It  should  be  emphasized,  though,  that  this  limit  could  be  a  user  parameter,  as 
advisory  messages  are  transmitted  for  all  encounters,  regardless  of  range. 


This  display,  although  still  unsophisticated,  does  require  a  considerable 
level  of  computational  power.  In  particular,  the  calculations  required  for 
the  relative  motion  vector  and  resolution  positioning  features  are  relatively 
complex. 


6.3  Sophisticated  Displays 


As  the  first  example  of  a  sophisticated  user  display,  consider  the  single 
encounter  alphanumeric  display  depicted  in  Figure  24.  With  this  display, 
complete  information  is  presented  for  the  most  critical  encounter.  If  other 
encounters  exist,  the  type  of  the  next  most  critical  is  shown  beside  the  next 
button.  By  pushing  this  button,  the  pilot  can  see  the  data  for  that  encounter. 
By  successive  pushes,  all  situations  can  be  viewed.  A  separate  button 
provides  for  immediate  return  to  the  most  critical  encounter. 

Track  numbers  must  be  employed  in  this  system  for  two  reasons.  First,  it 
is  the  only  method  that  could  be  used  to  correlate  start,  proximity,  and 
threat  messages  so  as  to  gather  together  and  compute  all  the  data  displayed 
for  an  encounter.  Second,  it  is  needed  to  insure  that  any  given  encounter 
stays  on  the  same  display  "page",  so  that  a  pilot  will  not  experience 
flicker. 

Finally,  the  full  graphics  system,  which  has  been  developed  as  part  of 
th<-  Lincoln  ATARS  program,  is  described  in  detail  in  the  remainder  of  this 
document. 
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Fig.  24.  Single  Encounter  Alphanumeric  Display 


7.0  LINCOLN  ATARS  GRAPHICS  DISPLAY 


The  graphics  display  developed  by  Lincoln  Laboratory  for  ATARS  testing  is 
a  subset  or  the  CRT  system  being  implemented  as  part  of  the  DABS  Data  Link 
program  (3j.  As  shown  in  Figure  25,  it  is  based  upon  a  Bendix  color  radar 
CRT.  The  screen  can  be  filled  with  13  lines  of  32  characters  each,  or  can 
have  various  graphic  symbols,  such  as  lines  and  arrows,  placed  at  any 
position.  In  addition,  several  different  colors  can  be  used  for  the  display. 
The  input  keyboard  can  be  used  to  enter  commands,  respond  to  screen  questions, 
or  control  the  display. 

In  operation,  the  display  will  be  tine-shared  between  the  ATARS,  Data 
Link,  and  weather  radar  functions,  with  relative  priorities  and  pilot  input 
determining  the  usage  at  ary  instant  of  time.  In  general,  whenever  a  threat 
situation  exists,  ATARS  will  be  in  control  of  the  display. 

This  chapter  and  the  twc  remaining  will  describe  the  overall  system,  user 
interaction,  and  software  implementation  respectively  of  this  graphic  display. 
A  fairly  complete  level  of  implementation  detail  will  be  provided  in  each 
case.  This  is  not  being  done  under  the  expectation  that  avionics 
manufacturers  will  c  -py  the  Lincoln  system,  as  it  was  never  intended  to  serve 
as  a  prototype.  Rather,  the  intent  of  this  discussion  is  to  present  the  many 
complex  anl  unusual  considerations  that  must  be  addressed  by  such 
manufacturers  when  developing  a  display  that  will  function  properly  under  both 
normal  and  extraordinary  operation  of  the  ATARS  ground  system. 

7 . 1  Graphic  Display  Format 

The  proposed  size  and  shape  for  the  nominal  ATARS  graphical  display 
region  is  computed  by  assuming  the  relative  aircraft  headings  and  velocities 
in  a  tnreat  encounter  are  ''optimal"  to  produce  the  minimum  time  to  collision. 
Assuming  a  maximum  speed  of  360  knots,  the  equation  for  the  50  second  boundary 
is: 


(l0  cos  0  O<0<45° 

P  =<  5/sin  0  45°<0<9O° 

I  5  90°<9<180° 

where  p  is  the  distance  between  the  aircraft  and  0  is  the  bearing  of  the  other 
aircraft  relative  to  the  heading  of  the  subject  aircraft.  The  first  two 
relations  are  exact,  while  the  last  is  a  simple  approximation  to  a  complex 
term.  Figure  26  illustrates  the  shape  of  this  display  region,  which  is  two 
semicircles  connected  by  a  fixed  width  segment.  Proximity  or  threat  aircraft 
located  outside  this  boundary  will  still  be  reported,  and  will  be  displayed  as 
explained  below. 

The  screen  format  when  ATARS  is  being  displayed  is  shown  by  Figure  27. 
Whenever  possible,  the  top  3  lines  are  reserved  for  critical  tactical  Data 
Link  messages.  Thus  these  messages  need  not  be  delayed,  nor  would  they  have  to 
displace  ATARS.  The  center  of  the  screen,  with  dimensions  matching  the  threat 
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Fig.  27.  ATARS  Screen  Format 


61 


region  just  calculated,  is  used  to  show  the  current  locations  of  all  encounter 
aircraft  and  the  projected  closest  approach  positions  of  all  threats.  Whenever 
a  threat  aircraft  is  located  within  the  dotted  region  shown  in  the  figure,  the 
Data  Link  area  is  reduced  to  a  single  line.  This  single  line  is  still 
sufficient  for  tactical  messages  provided  they  are  abbreviated.  Finally,  the 
side  panels  present  additional  alphanumeric  information  for  threat  situations. 
Each  such  encounter  requires  one  side;  thus,  the  additional  data  for  at  most 
two  threats  can  be  accommodated  at  one  time.  If  an  active  resolution  advisory 
exists,  it  is  presented  in  red  at  the  lower  right  of  the  display.  The  low=r 
left  corner  posts  the  current  display  format  parameters  in  effect  (defined  in 
section  8.2) . 

A  sample  maximum  format  ATARS  display,  shown  in  color  and  illustrating 
the  proposed  methods  for  presenting  the  data  for  aircraft  involved  in 
encounters  with  the  subject  aircraft,  is  given  by  Figure  28.  Threat  aircraft 
information  is  drawn  in  white,  proximity  information  in  green.  The  current 
relative  position  of  either  type  of  encounter  aircraft  is  marked  by  a  plus 
sign  at  the  proper  range  and  bearing.  This  symbol  may  have  any  or  all  of 
f'jur  diagonal  lines  added  to  indicate  the  following  status  situations: 

4-  aircraft  is  ATARS  equipped 
-£•  aircraft  is  controlled 
aircraft  is  a  threat 

aircraft  is  receiving  ATARS  resolution  advisories 

Above  the  symbol,  the  relative  altitude  of  the  encounter  aircraft  is  indicated 
by  a  signed  alphanume  ic  label,  such  as  +05  for  500  feet  above.  Threat 
encounters  may  in  addition  have  a  vertical  arrow  following  the  alphanumerics 
to  indicate  direction  of  vertical  speed,  if  any.  Originating  at  the 
position  symbol  is  an  arrow  whose  direction  and  length  represent  the  relative 
heading  and  speed  of  the  encounter  aircraft.  The  length  presents  the  distance 
to  be  traversed  by  the  aircraft  in  the  next  10  seconds,  except  that  minimum 
and  maximum  lengths  are  enforced.  In  addition,  the  end  of  this  arrow  will  be 
tilted  right  or  left  for  threat  encounters  if  the  aircraft  is  executing  a 
turn. 


Threat  encounter  representations  also  include  a  relative  motion  display 
component.  This  representation  includes  the  following  features: 

1.  an  X  marking  th  >  predicted  closest  point  of  approach  of  the 
threat  aircraft,  labelled  with  the  expected  relative  altitude 
at  that  time 

2.  a  relative  motion  line,  with  ten-second  tick  marks,  connecting 
the  current  position  symbol  for  the  threat  with  that  X 

3.  a  leader  line  to  the  side  of  the  display  on  which  the  time 
to  closest  approach  and  aircraft  information  for  the  threat 
are  listed. 
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If  any  encounter  is  out-of-range  for  the  display  area  dimensions,  it  is 
represented  by  a  triangle  on  the  perimeter  at  the  proper  current  relative 
bearing.  No  alphanumeric  information  is  included  in  this  case.  However,  if 
the  encounter  is  a  threat,  the  relative  motion  line  segment  for  the  display 
area  is  included,  as  is  the  closest  point  of  approach  information.  The  tick 
lines  are  deleted,  though,  as  they  would  be  meaningless  in  this  format. 

In  addition,  the  display  has  two  fixed  features.  First  is  an  asterisk 
for  the  subject  aircraft  with  an  arrow  whose  length  and  tilt  represent  its 
speed  and  turn  status  respectively.  Second  is  a  two  mile  range  ring  that 
supplies  a  range  reference  to  the  pilot.  If  the  pilot  is  interested  in 
encounters  at  greater  ranges,  or  if  the  current  threat  situation  is  such 
that  he  wants  an  expanded  screen,  he  can  scale  the  display  to  any  larger 
or  smaller  full  range  as  described  in  the  next  chapter. 

If  the  pilot  feels  that  the  display  format  described  above  is  too 
cluttered,  he  may  select  a  large  range  of  less  complete  formats.  For  example, 
he  may  choose  a  less  complete  picture  for  proximity  encounters,  either  a  point 
representation  (just  the  +  symbol)  or  no  indication  at  all.  Also,  he  may 
greatly  reduce  the  amount  of  alphanumeric  information  on  the  display,  such  as 
the  aircraft  information  sidebars.  Finally,  he  may  eliminate  relative  motion 
and  closest  approach  displays,  either  for  all  threats  for  just  for 
non-most-critical  ones.  A  description  of  all  such  options,  and  the  methods  to 
be  used  by  a  pilot  for  requesting  them,  are  presented  in  the  next  chapter. 

7.2  Microcomputer  System 

The  combined  Data  Link/ATARS  onboard  graphic  display  system  employs  a 
C'roraemco  microcomputer  to  process  uplink  messages  and  prepare  the  screen 
display.  This  computer  implements  an  interrupt  driven,  multi-tasking  system. 

A  schematic  block  diagram  of  this  system,  along  with  the  set  of  interrupts,  is 
presented  by  Figure  29.  The  program  flow  of  the  ATARS  tasks  within  this 
overall  structure  is  shown  in  Figure  30.  All  discussion  in  this  section  will 
be  in  reference  to  these  figures. 

In  the  usual  case,  this  system  is  activated  by  the  arrival  of  COMM-A 
messages  at  the  Standard  Message  Interface  (SMI).  These  messages  must 
immediately  be  transferred  to  a  storage  buffer,  so  that  the  system  can  be 
ready  to  receive  the  next  one.  The  potential  rapid  burst  rate  of  COMM-A 
messages  received  by  the  aircraft  during  the  sensor  dwell  time  precludes  the 
system  from  performing  any  further  message  processing  until  all  messages  for 
the  scan  have  been  received. 


Fig.  29.  Data  Link/ATARS  Computer  System 


The  criterion  used  to  determine  when  all  messages  have  been  received  is 
dead  time  since  the  last  one.  All  presently  planned  sensor  antennas  will  have 
a  dwell  time  less  than  100  milliseconds.  Thus,  a  100  millisecond  timer  has 
been  built  into  the  system.  Each  time  a  COMM-A  arrives,  this  timer  is  reset 
to  full  scale.  When  this  timer  finally  counts  down  to  zero,  an  interrupt  is 
generated  that  signals  the  scan  completion. 

After  this  interrupt  occurs,  the  COMM-A  messages  are  sorted  into  separate 
data  link  and  ATARS  buffers.  In  addition,  all  of  them  are  printed  onboard  in 
case  future  reference  or  playback  is  required.  The  ATARS  messages  are  decoded 
during  this  transfer  process,  each  field  being  unpacked  and  placed  into  a 
separate  word.  This  new  format  greatly  facilitates  downline  software 
processing. 

Since  the  computer  is  serving  many  functions  in  addition  to  ATARS 
processing,  a  task  scheduler  is  needed  to  arbitrate  when  several  tasks  are 
ready  to  run.  When  ATARS  processing  becomes  the  highest  priority  one  not  yet 
executed,  it  is  initiated.  This  processing  task  has  two  separate  components: 
encounter  file  updating  (or  tracking),  and  display  buffer  generation. 

The  tracking  routine  is  responsible  for  updating  the  position  and  status 
of  every  active  proximity  or  threat  encounter  for  the  aircraft.  Its  Inputs 
for  these  actions  are  the  current  scan  COMM-A  messages  and  the  previously 
received  information  as  stored  in  the  encounter  file.  The  set  of  possible 
actions  are  the  following: 

1.  update  an  existing  encounter  file  with  the  information  from  a 
new  COMM-A; 

2.  coast  an  encounter  file  for  which  no  COMM-A  was  received; 

3.  delete  an  out-of-date  encounter,  either  through  an  end  message 
or  via  timeout; 

4.  initiate  a  file  for  a  new  encounter. 

The  routine  also  maintains  current  information  on  the  own  aircraft  and 
resolution  states. 

Once  the  current  information  on  all  encounters  has  been  determined,  the 
ATARS  display  buffer  is  created.  This  buffer,  whose  format  is  described  in 
the  next  section,  serves  as  the  input  for  the  display  generation  task. 

In  addition,  a  system  priority  for  the  ATARS  display  is  also  generated. 
Since  the  ATARS  task  must  share  the  screen  with  data  link  or  weather  tasks,  a 
three  level  (high,  normal,  low)  priority  structure  has  been  created  to 
arbitrate  screen  access.  When  a  task  is  using  the  screen,  it  can  be  preempted 
only  by  a  task  of  a  higher  priority  level.  Tasks  of  the  same  or  lower  level 


are  buffered  to  await  their  turn.  When  the  screen  becomes  free,  the  highest 
priority  buffered  task  gains  access;  among  tasks  of  equal  priority,  the  one 
waiting  longest  is  chosen.  When  a  task  on  the  screen  is  preempted  by  a  higher 
priority  one,  it  is  placed  first  on  the  waiting  list  for  its  priority  level. 

Thus,  the  display  handler  compares  the  ATARS  priority  to  the  priorities 
of  any  other  entities  that  are  seeking  access  to  the  general  area  of  the 
display.  If  the  ATARS  priority  is  greater  than  or  equal  to  all  others,  as 
well  as  greater  than  that  of  the  current  display  on  the  CRT,  the  ATARS 
display  processor  is  executed.  The  current  display,  and  others  of  lower 
priority,  are  buffered  for  future  display.  On  the  other  hand,  if  ATARS  is 
lower  in  priority  than  other  display  users,  no  display  is  generated,  and  only 
an  “ATARS  PENDING"  message  is  provided.  (ATARS  displays  are  never  buffered, 
as  a  new  one  is  created  each  scan). 

The  ATARS  display  generation  task  is  responsible  for  translating  the 
display  buffer  into  a  format  suitable  for  driving  the  display  hardware. 
Positioned  symbols  with  associated  alp'nanumerics  and  character  strings  for  the 
two  side  areas  are  all  created  to  the  degree  and  complexity  specified  by  the 
display  level  chosen  by  the  operator.  The  next  two  chapters  discuss  these 
issues  in  greater  detail. 

If  tactical  data  link  messages  also  exist,  a  separate  tactical  area 
display  processor  is  responsible  for  formatting  the  top  area  of  the  screen  to 
display  them.  Either  one  or  three  lines  are  available  to  this  processor, 
depending  upon  the  location  of  ATARS  threats. 

Once  the  display  has  been  generated,  the  ATARS  tasks  enter  a  wait  state, 
awaiting  the  next  scan  COMM-A  messages.  However,  if  no  messages  were  to 
arrive,  these  tasks  would  not  be  executed,  and  the  current  display  would  show 
outdated  information.  To  prevent  such  an  occurrence,  a  separate  scan  timer 
set  to  150%  of  the  scan  time  is  activated  each  time  a  display  is  generated. 

If  it  times  out,  an  interrupt  is  generated  that  produces  a  new  pass  through 
the  ATARS  tasks.  Thus  updated  displays  are  produced,  including  the  null  one 
after  all  encounters  have  timed  out. 

The  remaining  boxes  on  Figure  29  are  for  the  most  part  related  to  the 
data  link  system.  Every  time  the  user  makes  a  keyboard  entry,  it  is 
interpreted  and  the  proper  action  executed.  This  could  be  to  add  to  the 
display  text  or  cause  a  menu  to  be  displayed,  for  example.  If  a  downlink 
message  has  been  generated,  it  is  entered  into  the  downlink  buffer  and  then 
transferred  to  the  SMI  at  the  proper  time.  Uplink  ELM  messages  are  buffered 
upon  reception,  and  displayed  when  the  system  priorities  permit  it.  Finally, 
a  2  Hertz  timer  provides  timing  interval  data  required  by  various  tasks. 
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7.3  ATARS  Internal  Files  and  Buffers 


The  ATARS  computer  employs  several  files  and  buffers  to  maintain  all  the 
historical  information  considered  useful  for  a  maximum  format  display.  This 
section  will  present  and  describe  the  most  important  of  these  data  structures. 
The  items  contained  in  each  one  are  important  to  note,  as  they  indicate  the 
types  of  information  that  must  be  considered  by  the  system  designer;  the 
actual  formats  chosen  for  the  structures  are  unimportant. 

An  encounter  file,  containing  the  information  shown  in  Figure  31,  is 
maintained  for  each  active  proximity  or  threat  encounter.  The  position 
quantities,  which  will  always  exist,  are  copied  from  the  most  recent  position 
data  set.  The  time  of  this  data  set,  taken  from  the  system  clock,  is  also 
recorded  to  permit  coasting  during  scans  on  which  no  message  is  received. 

If  the  encounter  is  not  brand  new  (NEW  bit  =  0  in  special  bits  word),  the 
positional  rates  are  calculated  onboard  from  three  successive  position 
messages  (only  two  for  the  encounter's  second  scan).  Instead  of  having  to 
store  two  scans  worth  of  position  data  to  permit  these  calculations,  a  single 
rate  direction  bit  is  maintained  for  each  rate  field.  This  bit  is  set  if  the 
rate  from  the  last  two  data  values  is  larger  than  the  value  in  the  encounter 
file.  This  knowledge,  plus  the  next  scan's  position  value,  is  sufficient  for 
a  three  scan  average.  The  applicable  formulas  are: 

new  position  -  old  position 

old  rate  + - +•  rate  bit 

scan  time 


new  position  -  old  position 

new  rate  bit  =  1  if  - >  new  rate 

scan  time 

The  velocity,  turn  type,  and  vertical  speed  information  will  be  known  for 
a  proximity  encounter  only  if  the  proper  messages  types  were  received:  a 
start  for  the  velocity,  supplementary  proximate  for  the  others.  Thus  two 
special  purpose  field  bits  are  needed  to  record  the  validity  of  these  fields. 
Note  that  a  zero  field  value  could  not  be  used  to  indicate  unkuo-fn  values,  as 
zero  is  in  fact  a  valid  number. 

If  the  encounter  is  a  threat,  the  miss  distance  field  will  apply.  Also, 
if  the  threat  is  not  new,  and  it  satisfies  other  necessary  conditions,  the 
calculations  in  the  Appendix  will  have  been  made  and  the  closest  point  of 
approach  position  and  time  fields  will  be  applicable;  the  CPA  valid  bit  in  the 
special  bits  word  indicates  when  this  has  occurred.  The  aircraft  information 
fields  are  reserved  for  such  information  as  aircraft  type,  operator,  and 
flight  number  when  the  data  becomes  available  to  ATARS. 
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Fig.  31  ATARS  Encounter  File 


The  four  track  number  fields  in  the  first  word  of  the  file  reflect  the 
fact  that,  in  the  absence  of  properly  coordinated  inter-sensor  communications, 
several  sensors  can  be  reporting  the  same  encounter,  each  using  a  different 
track  number.  Thus,  it  is  not  always  possible  for  the  encounter  file  number  to 
agree  with  the  message  track  number.  The  translation  from  message  number  to 
file  number  is  handled  by  the  array  shown  at  the  top  of  Figure  32.  In  each 
row,  indexed  by  message  track  number,  all  encounter  files  supported  by  a  track 
of  that  number  are  listed.  When  site  ID  bits  become  available  to  ATARS  the 
confusion  of  track  numbers  should  be  alleviated,  as  the  concatenation  of  the 
ID  and  track  number  fields  would  then  be  unique.  However,  some  error 
conditions  requiring  the  translation  array  could  still  exist. 

In  addition  to  encounter  files,  an  own  file  storing  all  attributes  of  the 
subject  aircraft  is  also  maintained.  Until  the  RAR  is  implemented,  this  file 
is  also  used  to  store  resolution  data.  Figure  32  presents  the  fields 
currently  defined  for  this  file.  Almost  all  of  the  data  is  copied  directly 
from  either  the  most  recent  own  or  resolution  data  sets.  The  times  of  each 
such  data  set  are  also  stored,  the  own  time  to  permit  calculation  of  current 
heading  via  the  turn  rate,  and  the  resolution  time  to  permit  timeout 
determination. 

The  remaining  three  own  file  data  items  are  calculated  by  the  computer. 
The  multi-site  count  is  zeroed  every  time  an  own  message  seam  bit  is  set,  and 
incremented  every  time  it  is  not.  When  this  count  reaches  three,  single 
sensor  coverage  is  again  assumed  by  the  correlation  software.  The  own 
acceleration  is  determined  from  successive  own  velocity  values,  and  is  used  to 
calculate  the  current  velocity.  The  largest  scan  rate  is  important  to  know 
during  multiple  sensor  situations,  as  the  scan  timer  discussed  earlier  must  be 
set  larger  than  the  period  of  any  sensor  uplinking  messages.  The  stored  value 
is  updated  every  time  an  own  data  set  is  received  as  the  weighted  average  of 
the  old  value  and  the  new  own  data  set  scan  value.  This  action  removes  the 
influence  of  sensors  no  longer  uplinking  messages. 

Whenever  a  new  display  picture  is  to  be  created  by  the  display  routine, 
the  tracking  routine  constructs  a  display  buffer  of  the  form  shown  in 
Figure  33  from  the  information  contained  in  the  files  just  described.  The 
formats  for  each  type  of  encounter  entry  are  shown  by  Figure  34.  A  proximity 
encounter  requires  only  one  such  entry,  while  a  threat  requires  two  successive 
entries  for  complete  definition.  The  header  entry  provides  buffer  processing 
information,  the  settings  of  the  display  parameters  (described  in  the  next 
chapter),  own  aircraft  information,  and  the  current  resolution  set.  It  also 
has  a  3-second  bit  which,  when  set,  informs  the  display  that  less  than  3 
seconds  have  elapsed  since  the  last  buffer  was  presented.  Many  displays 
should  not  be  updated  this  quickly  for  reasons  of  pilot  comprehension. 

If  an  encounter  was  updated  on  tb  current  scan,  its  display  buffer 
information  is  copied  directly  from  it  . ncounter  file.  The  various  validity 
bits  indicate  whether  the  corresponding  fields  (velocity,  turn  type  and 
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Fig.  32.  Auxiliary  Encounter  Files. 
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vertical  speed,  CIA  bearing  and  altitude  and  time)  are  known  or  not,  and  thus 
whether  or  not  the  display  can  utilize  them.  If  the  encounter  was  not 
updated,  the  data  fields  are  produced  by  coasting  the  last  known  position 
values  to  the  current  time  via  the  rate  quantities  residing  in  the  encounter 
file. 

The  display  buffer  creation  routine  must  also  insure  that  one  and  only 
one  encounter  entry  contains  a  most  critical  bit,  to  insure  proper  display 
generation.  Various  error  conditions  could  result  in  none  or  several 
encounter  files  having  this  bit  set.  Examples  of  these  are: 

1.  the  uplink  position  message  with  the  most  critical  bit  set  was 
not  received 

2.  the  current  scan  aessage  for  the  previous  scan’s  most  critical 
encounter  was  not  received,  hence  it  and  the  new  most 
critical  encounter  are  both  so  labelled 

3.  two  ground  sensors  disagree  on  the  most  critical  encounter 

4.  the  ground  logic  fails. 

The  last  chapter  presents  the  onboard  logic  to  either  choose  one  most  critical 
encounter  when  none  exists  or  arbitrate  when  several  exist. 


The  display  buffer  has  been  designed  to  meet  the  needs  of  any  graphic  or 
alphanumeric  display  device.  Thus,  just  bv  changing  the  display  subroutine  to 
match  the  new  display  characteristics,  the  tracking  software  that  produces 
this  buffer  can  be  used  without  modification. 


8.0  AID  USER  SELECTABLE  FEATURES 

The  Lincoln  developed  experimental  ATARS  graphics  display,  known  as  the 
Airborne  Intelligent  Display  (AID),  contains  a  number  of  selectable  features 
to  facilitate  testing.  While  some  of  these  user  options  may  remain  on 
operational  systems,  many  others  will  be  replaced  by  fixed  settings  at 
the  values  determined  to  be  optimum. 

The  previous  chapter  has  described  the  maximum  information  format  ATARS 
display.  Although  in  theory  all  the  information  on  the  display  should  be 
useful  to  the  pilot,  preliminary  tests  and  observations  have  shown  that  the 
resulting  screen  is  often  too  cluttered  to  be  readable.  Thus,  several  reduced 
display  formats  have  been  built  into  the  AID.  The  gross  amount  of  display 
information  is  controlled  by  a  parameter  called  the  display  level,  while  the 
fine  tuning  within  each  level  is  controlled  by  three  other  parameters:  screen 
range,  proximity  display  mode,  and  proximity  display  priority.  Also,  the 
color  of  any  display  item  can  be  altered  as  desired.  The  full  complement  of 
display  formats  possible  via  different  settings  of  these  parameters  is 
described  in  this  chapter.  Also,  the  methods  by  which  a  user  can  enter  values 
for  each  parameter  are  presented. 

Since  the  AID  is  being  used  in  an  experimental  system,  various  debug 
features  have  been  built  into  it.  These  features,  described  in  section  8.4, 
permit  operation  of  both  the  ATARS  ground  system  and  the  onboard  avionics  to 
be  investigated.  They  also  help  to  pinpoint  the  causes  of  any  errors  that 
might  arise  during  the  test  program. 

8. I  ATARS  Display  Levels 


Ten  levels  of  ATARS  display,  ranging  fr  m  the  full  format  described  in 
the  last  chapter  all  the  way  down  to  resolution  advisories  only,  with  no 
graphic  display  or  encounter  information,  have  been  defined  por  the  AID. 
Figure  35  describes  how  much  the  information  set  is  reduced  as  the  level 
setting  is  lowered.  Figure  36  provides  an  alternate  description  of  the 
various  levels  by  listing  the  format  for  each  type  of  screen  entity  as  a 
function  of  level. 

The  remainder  of  this  section  provides  an  expanded  description  of  each 
level,  along  with  notes  and  comments  on  the  advantages  and  disadvantages  of 
the  ten  formats.  Figures  37  through  46  give  pictorial  examples  of  how  the 
display  screen  would  appear  at  each  level  for  two  different  encounter  mixes: 
two  threats,  and  one  threat  and  two  proximities. 

Level  9  -  Maximum  Information 


This  level  provides  all  possible  information  on  all  encounters  as  well  as 
the  settings  of  the  display  parameters.  Although  apparently  giving  the  pilot 
the  ability  to  make  the  best  decisions,  the  mass  of  screen  information  in 
actuality  can  prevent  him  from  locating  the  key  items  before  a  new  display 
appears.  Also,  so  much  alphanumeric  information  exists  that  some  of  it  can  be 
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Level  and  Menu  Name 


Display  Format 


9  -  ABS  MAX 

8  -  TWO  MAX 

7  -  ONE  MAX 

6  -  TWO  INF 

5  -  ONE  INF 

4  -  TWO  THT 

3  -  ONE  THT 

2  -  MIN  HDG 

I  -  MIN  CTL 

0  -  ABS  MIN 

Fig.  35. 


Full  information  format  as  described 
in  section  7.1,  with  relative  motion 
and  aircraft  information  on  up  to 
two  threats. 

Same  as  9,  except  that  display 
parameter  values  are  not  listed. 

Same  as  8,  except  that  relative  motion 
and  aircraft  information  is  provided 
only  for  the  most  critical  threat. 

Same  as  8,  except  that  altitude  at  CPA  is 
no  longer  provided  for  either  threat. 

Same  as  7,  except  that  altitude  at  CPA  is 
no  longer  p-ovided  for  the  most  critical 
threat. 

Same  as  6,  exeat-:  that  aircraft  information 
is  no  longer  provided  for  either  threat, 
and  thus  onl>  time  to  CPA  is  given  in  the 
sidebar  areas. 

Same  as  5,  except  that  aircraft  information 
is  no  longer  provided  for  the  most  critical 
threat  and  the  sidebar  boxes  are  removed, 
although  the  time  to  CPA  for  the  most 
critical  threat  is  still  shown  on  the  side 
of  the  display. 

Same  as  3,  except  that  neither  relative 
motion  information  nor  time  to  CPA  is 
provided  for  any  threat. 

Same  as  2,  except  that  no  heading  vector 
is  provided  for  proximity  aircraft  and  no 
turn  indications  given  for  threat  or  own 
aircraft. 

Only  resolution  advisories  are  displayed, 
with  no  graphic  encounter  picture  at  all. 


Reduction  of  Display  Format  with  Level. 
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Fig.  36.  ATARS  Display  Features  vs.  Level. 
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FIG.  40.  SAMPLE  LEVEL  6  SCENARIOS 
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overwritten  and  thus  lost.  This  is  particularly  true  for  altitude  at  CPA. 

Both  level  9  displays  in  Fig.  37  suffer  this  problem.  In  one  case,  the  entire 
altitude  is  missing,  while  in  the  other  its  sign  has  been  lost.  In 
conclusion,  although  level  9  is  of  interest  in  showing  the  amount  of  data 
resident  in  ATARS,  it  is  probably  not  a  viable  operational  choice. 

Level  8  -  Two  Threat  Maximum 

This  level  provides  the  identical  encounter  display  as  the  previous 
level  9.  The  only  difference  is  that  the  display  parameter  values  are  no 
longer  posted.  If,  as  expected,  a  pilot  will  initialize  these  parameters  to 
accustomed  values,  and  not  change  them  during  a  flight,  eliminating  the 
parameter  data  reduces  screen  clutter  at  no  cost.  However,  if  parameter 
changes  are  found  to  be  useful  according  to  the  ATARS  situation,  the  pilot 
would  need  to  know  their  current  values.  If  this  is  found  to  be  true  during 
tests,  introducing  the  parameter  posting  into  other  lower  levels  may  be 
required. 

Level  7  -  One  Threat  Maximum 

If  it  is  true  that  a  pilot  can  concentrate  and  plan  strategy  on  only  one 
threat  at  a  time,  then  removing  the  relative  motion  display  for  the  secondary 
threat  will  help  him  in  this  effort.  The  second  threat  data  will  no  longer 
divert  his  attention  or  interfere  with  the  display  of  the  primary  information. 
The  current  position  and  heading  of  the  secondary  threat  will  still  remain  on 
the  screen,  of  course,  so  some  avoidance  information  would  still  exist. 

Level  6  -  Two  Threat  Information 

This  level  has  removed  the  altitude  at  the  threat’s  closest  point  of 
approach.  Because  of  its  positioning  near  the  center  of  the  screen,  this 
alphanumeric  tag  tends  to  interfere  with  other  more  important  data.  If  CPA 
altitude  is  felt  to  be  useful,  it  could  be  displayed  in  the  sidebar  areas. 

All  other  threat  information,  namely  relative  motion-  range  and  bearing  and 
time  to  CPA,  and  aircraft  information,  still  exist  on  this  level. 

Level  5  -  One  Threat  Information 

This  level  is  the  same  as  the  previous  level  6  except  that  the  auxiliary 
threat  information  is  provided  for  only  the  most  critical  threat.  The 
discussion  under  level  7  applies  here  as  well. 

Level  4  -  Two  Threat  Relative  Motion 

This  level  has  further  reduced  the  maximum  display  format  by  removing  the 
aircraft  information  data  from  the  screen.  This  data,  namely  aircraft  type, 
airline  operator,  and  flight  number,  was  intended  fwhen  available)  to  aid  the 
pilot  in  identifying  the  threat  aircraft.  However,  it  does  take  time  to  read 
and  removes  the  pilot's  attention  from  the  graphic  area  of  the  display.  Only 
testing  and  evaluation  can  determine  whether  this  information  is  a  help  or  a 


hindrance,  and  thus  whether  level  4  is  an  improvement  over  level  6.  The 
threat  relative  motion  information,  namely  the  relative  motion  line,  CPA  range 
and  bearing,  and  time  to  CPA,  still  remain  for  both  threats  at  this  level. 

Level  3  -  One  Threat  Relative  Motion 

This  level  presents  the  same  level  of  threat  data  as  level  4,  but  only 
for  the  most  critical  threat.  Thus,  the  discussion  under  level  7  is  again 
applicable.  In  addition,  since  the  total  sidebar  information  has  now  been 
reduced  to  a  single  time  to  CPA  for  the  most  critical  threat,  the  side  boxes 
are  no  longer  required.  This  reduction  alone  has  led  many  observers  to  favor 
level  3.  The  combination  of  the  most  important  relative  motion  information 
for  the  most  critical  threat  and  a  minimum  of  screen  clutter  makes  this  level 
a  strong  favorite  to  be  chosen  as  the  best.  It  is  currently  the  default  level 
for  the  AID  display. 

Level  2  -  Minimum  Display  with  Headings 

This  level  provides  full  information  on  the  current  positions,  status, 
and  headings  of  all  aircraft,  including  the  turn  status  of  the  own  and  all 
threat  aircraft.  No  relative  motion  or  CPA  data  is  any  longer  provided,  even 
for  the  most  critical  threat.  This  level  will  be  chosen  if  relative  motion 
information  is  rejected  by  pilots.  Possible  reasons  for  such  a  decision  are 
that  it  varies  too  much  from  scan  to  scan  to  be  useful  or  that  it  takes  too 
much  time  and  effort  to  assimilate.  Only  testing  can  lead  to  proper 
evaluation  of  relative  motion  data. 

Level  1  -  Minimum  Display 

This  level  provides  the  minimum  graphic  display  felt  to  be  feasible  for 
ATARS.  The  current  range,  bearing,  and  altitude  is  provided  for  all  encounter 
aircraft.  In  addition,  the  control  status,  namely  whether  or  not  ATARS 
equipped,  whether  or  not  controlled,  and  whether  or  not  receiving  an  ATARS 
resolution  advisory  (threats  only),  is  shown.  Finally,  the  heading  arrow  for 
threat  aircraft  is  drawn  to  provide  the  minimum  level  of  motion  data  that 
would  still  provide  pilots  with  some  ability  to  plan  strategy.  This  level 
provides  a  lower  bound  for  ATARS  presentations. 

Level  0  -  Resolution  Advisories  Only 

Some  pilots  may  not  want  to  take  any  collision  avoidance  action  at  all  on 
their  own.  For  them,  this  level  is  ideal.  However,  since  no  graphic  display 
of  any  kind  is  provided,  pilots  will  receive  no  advance  warning  of  the 
resolution  advisory. 


It  is  of  course  clear  that  many  other  levels  of  ATARS  display  could  be 
developed.  If  during  testing  certain  features  are  found  to  be  useful,  they 
could  be  added  to  levels  that  do  not  presently  contain  them.  For  example, 
aircraft  information  could  exist  even  at  level  1  if  so  desired. 
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After  testing  is  completed,  two  different  types  of  decisions  could 
result.  First,  one  level  could  be  found  to  be  far  superior  to  all  others,  and 
only  it  is  provided  in  commercial  displays.  Alternatively,  several  levels 
could  be  found  appealing  to  various  groups  of  pilots,  and  pilot  option  would 
remain  built  into  the  displays.  The  first  is  cheaper,  the  second  more 
flexible. 


8.2  AID  Display  Parameters 


The  previous  section  discussed  how  a  pilot  can  select  the  ensemble  of 
information  he  would  like  on  his  ATARS  display.  This  section  describes  the 
display  parameters  that  determine  the  exact  manner  in  which  this  information 
is  presented.  In  particular,  they  control  the  scale  of  the  display  region, 
the  degree  of  proximity  detail  as  a  function  of  threat  situation,  the  relative 
priority  of  ATARS  versus  other  data  link  uses,  and  the  color  employed  for  each 
feature  of  the  display. 

8.2.1  Screen  Range  (RNG) 

The  RNG  parameter  defines  the  maximum  distance  from  the  own  aircraft 
within  which  all  encounter  positions  are  guaranteed  to  be  in  the  displayable 
region.  As  shown  previously  in  Fig.  26,  this  region  is  rectangular  rather 
than  circular,  so  that  longer  distances  are  displayable  at  most  bearings. 

Also,  the  region  was  designed  to  extend  a  minimum  distance  of  2*RNG  in  the 
forward  direction,  as  closing  speeds  are  higher  for  head-on  encounters.  Any 
encounter  that  is  out-of-scale  for  the  display  region  is  shown  as  a  triangle 
without  alphanumeric  altitude  on  the  display  perimeter.  Thus,  although  it 
still  is  shown,  range  and  altitude  information  is  lost. 

Two  different  types  of  screen  range  settings  are  possible:  manual  and 
automatic.  With  the  former,  the  screen  scale  remains  constant  from  scan  to 
scan  at  the  pilot  set  value.  With  the  latter,  however,  the  scale  will  vary 
according  to  the  encounter  situation,  and  thus  changes  from  scan  to  scan  are 
possible. 

To  establish  a  manual  range,  RNG  is  set  to  a  value  between  2  and  8 
nautical  miles  inclusive.  This  value  is  then  used  as  the  constant  screen 
range.  The  remaining  integer  values,  if  set  by  the  user,  signal  an  automatic 
range  mode.  The  interpretations  are  as  follows: 

RNG  =  0:  each  scan,  choose  the  smallest  screen  range  setting  that 

permits  all  encounters  to  be  within  the  displayable  region. 

RNG  =  1:  each  scan,  choose  the  smallest  screen  range  setting  that 

permits  all  threat  encounters  to  be  within  the  displayable 
region  (proximity  encounters  may  be  off  scale);  if  no  threat 
encounter  exists  on  a  scan,  proceed  as  if  RNG  =  0. 
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RNG  =  9:  each  scan,  choose  the  smallest  screen  range  setting  that 
permits  the  most  critical  encounter  to  be  within  the 
displayable  region;  other  threat  or  proximity  encounters  may  be 
off  scale. 

The  screen  range  can  vary  between  2  and  13  nautical  miles  in  these 
automatic  modes.  Each  scan,  the  proper  value  is  calculated  by  the  display 
processor  from  the  active  encounter  range  and  relative  bearing  data.  Note 
that  range  data  alone  is  not  sufficient,  as  the  displayable  area  has  a 
different  physical  length  for  each  bearing.  Thus,  for  example,  if  a  single 
encounter  at  9.7  miles  exists,  the  screen  range  would  have  to  be  set  to  10 
miles  if  the  encounter  were  at  90°,  but  only  7  miles  if  the  bearing  were  135°, 
and  just  5  miles  if  it  were  straight  ahead. 

Automatic  range  modes  have  both  advantages  and  disadvantages.  The  main 
advantage  is  that  no  pilot  intervention  is  required  to  produce  the  best 
display  scaling.  In  particular,  every  time  a  threat  pops  up,  the  display  will 
be  optimum  for  pilot  data  assimilation.  With  manual  range  modes,  the  setting 
could  be  too  small,  producing  off-scale  loss  of  information,  or  too  large, 
producing  relative  motion  data  too  compressed  to  be  readable.  The  main 
disadvantage  of  the  automatic  modes  is  sudden  jumps  in  the  frame  of  reference. 
Each  time  the  screen  range  changes,  the  pilot  must  reorient  hinself  before  he 
can  continue  his  monitoring  of  the  encounter  status.  Only  testing  can 
determine  how  serious  such  jumps  are  to  pilot  concentration. 

Figure  47  illustrates  how  proper  and  improper  range  settings  can  effect 
the  ATARS  display.  The  top  picture  was  made  using  an  automatic  mode,  and  so 
all  data  appears,  as  readably  as  possible.  The  bottom  picture  corresponds  to 
RNG=2.  Both  threats  are  now  off  scale,  and  current  position  data  is  lacking. 

The  AID  default  value  is  RNG=9,  providing  an  optimum  display  for  the  most 
critical  encounter. 

8.2.2  Proximity  Display  Mode  (PPM) 


Proximity  encounters  are  much  less  important  to  the  pilot  than  are 
threats.  In  particular,  a  pilot  must  make  a  positive  reaction  to  the  presence 
of  a  threat,  while  a  proximity  advisory  is  basically  infrrmatory  in  nature. 
Thus,  the  pilot  may  not  desire  the  complete  position,  altitude,  and  heading 
format  for  a  proximity  as  defined  in  the  previous  section.  This  may 
expecially  be  true  when  a  threat  encounter  also  exists,  as  th^s  full 
representation  may  overcrowd  the  display  and  obscure  the  threat  information. 

In  fact,  if  great  care  is  not  taken  in  the  display  processor,  the  proximity 
alphanumerics  or  heading  vector  could  overwrite  some  of  the  threat  features. 
(The  AID  has  this  drawback;  commercial  displays  should  avoid  it).  For  this 
reason,  a  pilot  may  find  a  simple  position  symbol  for  the  proximity  better 
suited  to  his  needs. 
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FIG.  47.  EFFECT  OF  RNG  PARAMETER  CHANGE 


Some  pilots  may  only  want  traffic  advisory  information  in  threat 
situations.  Such  a  pilot  will  be  uninterested  in  seeing  any  proximity 
representation  at  all  when  no  threats  exist.  However,  when  a  threat  is  present, 
he  will  need  at  least  an  indication  of  the  position  of  proximity  aircraft  to 
fully  understand  the  encounters. 

In  order  to  allow  the  pilot  to  select  his  desired  combination  of 
proximity  formats  for  threatening  and  non-threatening  situations,  the  system 
is  equipped  with  a  proximity  display  mode  parameter.  The  four  states  of  this 
parameter  provide  the  following  proximity  format  options: 

PPM  Option  When  a  threat  exists  When  no  threat  exists 

a  Pull  Full 

b  Point  Full 

c  Point  Point 

d  Point  None 

where: 

Full:  +  symbol  with  ATARS  and  control  indicators,  altitude  alphanumerics, 
heading  vector 

Point:  +  symbol  with  ATARS  and  control  indicators 

None:  no  indication 

The  first  option  provides  maximum  information  at  all  times.  The  second 
reduces  the  potential  clutter  when  threats  are  present.  The  third  signifies  the 
lower  importance  of  proximity  advisories  at  all  times  while  still  noting  their 
presence.  The  final  one  provides  proximity  presence  data  only  when  threats 
co-exist  and  maneuvers  could  be  contemplated. 

Observations  at  Lincoln  of  screen  clutter  during  threats  have  led  to  the 
belief  that  it  is  a  sufficiently  serious  problem  that  the  PDM  default  option  has 
been  set  to  b,  point/ full.  Figure  48  indicates  the  screen  appearance 
differences  of  point  versus  full  format  when  threats  are  present. 


The  AID  is  used  to  display  ATARS  encounters,  data  link  messages,  and 
weather  radar  data.  The  most  important  of  these  competing  users  is  clearly 
ATARS  when  a  threat  situation  exists.  Thus,  as  long  as  a  threat  encounter  is 
active,  ATARS  is  guaranteed  access  to  the  screen.  However,  as  described 
earlier,  tactical  data  link  messages,  also  important  to  the  pilot,  can  co-exist 
on  the  display  with  ATARS. 


Proximity  advisories,  on  the  other  hand,  are  not  critical  and  do  not 
require  pilot  action.  Thus,  a  pilot  may  not  want  them  to  preempt  the  screen 
when  he  is  in  the  midst  of  requesting  or  reading  a  data  link  message.  He  may 
not  even  wish  to  see  them  while  he  is  viewing  weather  data,  normally  the 
lowest  priority  system  user.  The  proximity  display  priority  parameter  permits 
the  pilot  to  rank  non-threat  ATARS  situations  according  to  his  personal  view 
of  their  importance. 

The  screen  access  priority  structure  recognizes  three  priority  levels: 
high,  normal,  and  low.  As  explained  in  chapter  7,  a  current  display  can  be 
preempted  only  by  a  display  of  higher  priority;  equal  or  lower  priority 
displays  are  buffered  until  their  turn  arises.  The  fixed  priority  assignments 
are  currently  as  follows: 

high:  ATARS  with  threat  encounters 

normal:  data  link  messages,  menus 
low:  weather  radar 

Thus,  if  PRI  is  set  to  high,  any  ATARS  display,  with  or  without  threats,  will 
appear  immediately  and  preempt  other  display  uses.  If  PRI  is  set  to  normal 
the  pilot  will  be  able  to  complete  his  ongoing  data  link  interaction  before 
non-threat  ATARS  displays  will  appear;  weather  data,  however,  will  immediately 
disappear.  Finally,  if  PRI  is  set  low,  non-threat  ATARS  displays  will  appear 
only  when  the  screen  is  not  currently  in  use. 

The  AID  default  value  for  PRI  is  normal. 

8.2.4  Feature  Colors 


To  provide  human  factors  engineers  with  the  flexibility  to  determine  proper 
color  settings  for  the  ATARS  display,  each  feature  in  the  AID  display  has  a 
separate  parameter  controlling  its  color.  The  list  of  features,  and  the  current 
default  color  for  each,  is  provided  in  Figure  49.  Figure  28  presented  a  color 
picture  of  a  current  ATARS  display  with  these  color  choices. 

The  AID  has  8  different  colors  available  for  display,  with  Figure  49  also 
specifying  this  list.  Any  of  these  colors  can  be  assigned  to  a  feature, 
independent  of  any  other  feature.  The  next  section  describes  the  procedure  for 
specifying  the  desired  color  to  feature  assignment. 
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Feature  # 

Feature 

Default  Color 

0 

Resolution  Advisory 

Red 

1 

Threat  Encounter 

White 

2 

Proximity  Encounter 

Green 

3 

Sidebar  Legend 

Yellow 

4 

Own  Aircraft 

Yellow 

5 

Threat  Sidebar  Leader 

Yellow 

6 

Parameter  Posting 

Green 

Color  # 

Color 

0 

Black 

1 

Blue 

2 

Green 

3 

Light  Blue 

4 

Red 

5 

Violet 

6 

Yellow 

7 

White 

Fig.  49. 

ATARS  Features  and  Colors. 
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S.3  ATARS  Parameter  Entry  Procedures 


The  ATARS  display  parameters  described  in  the  previous  two  sections  are 
all  alterable  by  pilot  interaction  with  the  AID  via  the  control  keyboard.  Any 
of  these  parameters  can  be  changed  at  any  time,  whether  or  not  an  ATARS 
display  currently  exists.  However,  the  procedure  will  differ  between  these 
cases  for  some  of  the  parameters. 

A  special  control  key,  labelled  RNGE,  has  been  provided  for  entering  new 
values  of  the  screen  range  parameter.  By  pressing  this  key,  followed  by  the 
pressing  of  any  numeric  key  (0  through  9),  a  new  screen  range  value  is 
defined,  with  the  corresponding  meaning  as  described  in  section  8.2.1.  This 
action  can  be  taken  at  any  time,  independent  of  the  screen  usage  status  of  the 
AID.  If  an  improper  key  is  pressed  by  accident  following  RNGE,  the  system 
will  wait  for  a  proper  entry.  Thus,  the  only  procedure  for  cancelling  a 
screen  range  change  once  begun  is  to  enter  the  current  parameter  value. 

All  other  AID  parameters  are  altered  through  reference  to  the  proper 
ATARS  menu.  Accessing  an  ATARS  menu  while  the  system  is  in  a  data  link  mode 
(no  ATARS  display  on  the  screen)  requires  proceeding  first  through  the  data 
link  menu.  This  menu,  illustrated  in  Figure  50,  appears  when  the  MENU  key  is 
pressed.  By  then  pressing  the  numeric  0  key,  as  stated  on  the  selection  list, 
the  first  ATARS  menu,  shown  in  Figure  51,  appears.  The  pressing  of  the  MENU 
key  is  optional,  as  the  system  resides  in  the  acceptance  state  for  data  link 
menu  en'.ries  in  any  event.  Thus,  a  numeric  0  entry  by  itself  will  suffice  to 
acceso  the  first  ATARS  menu. 

When  the  system  is  currently  in  an  active  ATARS  state,  that  is  when  ATARS 
scenarios  are  being  displayed,  the  system  residency  switches  to  the  first 
ATARS  menu.  Thus  the  two  steps  of  pressing  the  MENU  and  numeric  0  keys  are  no 
longer  required,  as  this  menu  is  already  active.  In  fact,  pressing  the  MENU 
key  will  sound  an  invalid  e*-  :ry  tone,  while  the  numeric  0  entry  will  be 
ignored.  (It  is  treated  as  an  exit  from  the  first  ATARS  menu,  which  merely 
leaves  the  system  where  it  already  was.) 

If  the  operator  actually  needs  to  view  the  first  ATARS  menu  during  an 
active  ATARS  period,  because  he  has  forgotten  its  selection  ordering,  he  must 
use  the  following  procedure.  First,  he  must  press  numeric  3,  which  sets  the 
proximity  priority  to  low.  Then  he  can  press  the  MENU  key  to  fall  back  to  the 
normal  priority  data  link  menu  whenever  no  threats  exist.  Finally,  a  numeric 
0  entry  retrieves  the  first  ATARS  menu.  This  menu  will  immediately  be 
preempted,  though,  if  a  high  priority  threat  encounter  appears. 
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ATARS 

SELECT 

ONE  O-NO  OPT 

PROX  PRI 

PROX  nooE 

OPT 

NO-  THR 

1  HIGH 

OPT 

4 

FULL 

2  ROM 

5 

FULL 

6 

POINT 

3  LOU 

7 

NONE 

FIG.  SI.  FIRST  ATARS  MENU 
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This  first  ATARS  menu  provides  the  means  for  changing  either  the 
proximity  display  priority  (PRI)  or  the  proximity  display  mode  (PDM):  a 
numeric  entry  of  1  through  3  sets  the  value  of  PRI,  while  a  numeric  entry  of  4 
through  7  sets  a  new  value  of  PDM.  The  interpretations  of  each  integer  entry 
are  as  defined  in  Figure  51;  the  detailed  explanations  of  each  parameter 
setting  were  provided  in  sections  £.2.2  and  8.2.3. 

If  the  operator  accessed  this  menu  accidentally,  such  as  by  making  the 
wrong  selection  from  the  data  link  menu,  he  can  exit  by  pressing  the  numeric  0 
key.  The  other  remaining  numeric  values,  namely  8  and  9,  lead  to  other  ATARS 
menus:  8  for  display  level  selection,  and  9  for  color  selection.  Neither  of 
these  options  are  described  on  the  menu,  as  they  are  felt  to  be  most 
applicable  for  test  purposes.  Thus,  they  are  "hidden"  from  the  pilot.  The 
pressing  of  any  non-numeric  key  while  the  menu  is  active  is  ignored  by  the 
system. 

The  ATARS  display  level  menu  is  presented  in  Figure  52.  As  shown,  any  of 
the  ten  possible  levels,  0  through  9,  can  be  set  by  pressing  the  corresponding 
numeric  key.  Section  8.1  defined  each  such  level  in  detail.  The  only  exit 
from  this  menu  is  by  pressing  a  valid  key. 

Finally,  pressing  a  9  from  the  first  ATARS  menu  permits  changing  any  of 
the  screen  feature  colors.  No  color  menu  will  appear,  as  the  AID  has 
insufficient  remaining  memory  for  its  definition.  Two  numeric  key  entries  are 
required  to  alter  a  color  parameter:  the  first  selects  the  feature  whose  color 
is  to  be  changed,  the  second  selects  the  color  to  be  used.  Figure  49 
presented  the  number-to-selection  lists  for  each  entry.  Any  invalid  keys  are 
ignored  for  either  entry. 

Figure  53  presents  detailed  examples  of  the  procedures  described  in  this 
section  for  altering  each  of  the  AID  parameters.  The  first  example 
demonstrates  the  preferred  method  for  expanding  the  screen  range  to  bring  an 
encounter  within  scale,  which  is  to  invoke  the  automatic  all-encounter  mode. 
The  second  example  indicates  that  while  ATARS  is  active,  the  first  ATARS  menu 
is  set  to  accept  inputs,  and  thus  only  a  single  key  entry  is  required  to 
change  the  PDM  setting.  The  third  example  shows  how  the  ATARS  menu  is 
accessed  when  ATARS  is  not  currently  being  displayed.  In  that  case,  the  data 
link  to  ATARS  menu  transition  is  required.  The  last  two  examples  demonstrate 
the  methods  for  making  selections  from  the  second  and  third  ATARS  menus,  both 
from  data  link  and  ATARS  system  states. 

8.4  AID  Debug  Features 


The  AID  system  has  several  built-in  features  tc  permit  verification  of 
the  proper  operation  of  the  overall  ATARS  system  and  to  help  in  pinpointing 
the  sources  of  errors  during  system  failure.  The  main  such  features  are 
uplink  message  printout,  input  and  output  ATARS  buffer  recording,  and  memory 
dump  upon  operator  command. 
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Example  1;  Screen  Range  Adjustment 


Situation:  The  current  ATARS  display  contains  a  triangle,  indicating  an  off-scale 
encounter.  The  pilot  wishes  to  expand  the  screen  range  to  locace 
the  encounter. 


Procedure:  1.  Press  RNGE  key  on  keyboard. 

2.  Press  numeric  key  0. 

Result:  Screen  range  increases  enough  to  include  the  off-scale  encounter.  If 

the  pilot  prefers  a  manual  screen  range  setting,  he  can  estimate  the 
encounter  range  and  set  the  screen  range  parameter  accordingly. 


Example  2:  Proximity  Mode  Change 


Situation: 

Procedure: 

Result: 


Full  format  proximity  encounter  representations  are  making  it  hard  for 
the  pilot  to  read  the  data  on  a  threat  encounter. 

1.  Press  numeric  key  5. 

The  proximity  encounter  representations  change  to  a  point  format  as 
long  as  a  threat  exists. 


Example  3:  Proximity  Priority  Change 

Situation:  The  pilot  is  viewing  low  priority  weather  data.  Proximity  encounters, 
set  at  normal  priority,  have  been  interrupting  his  display. 

Procedure:  1.  Press  MENU  key  (optional)  -  data  link  menu  appears. 

2.  Press  numeric  key  0  -  ATARS  menu  appears. 

3.  Press  numeric  key  3. 

Result:  ATARS  proxim.-ies  are  now  low  priority,  and  so  can  no  longer  preempt 

the  equal  priority  weather  data. 


Fig.  53.  ATARS  Parameter  Change  Examples  (1  of  2). 
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Example  4:  ATARS  Level  Change 


Situation: 


Procedure: 

Result: 


Example  5: 


Situation: 


Procedure: 


Result: 


The  ATARS  display  is  at  level  2,  producing  no  relative  motion  data 
for  a  threat.  The  pilot  decides  such  information  would  aid  in  his 
selection  of  avoidance  maneuvers. 

1.  Press  numeric  key  8  -  accesses  level  menu  (no  menu  appears). 

2.  Press  numeric  key  3. 

The  display  is  now  at  level  3,  and  CPA  range,  bearing,  and  time  will 
appear  for  the  threat. 


Color  Change 


A  human  factors  engineer  wishes  to  study  the  effect  of  light  blue 
threat  information  on  pilot  awareness  and  comprehension  in  his  next 
test. 


1.  Press  MENU  key  (optional)  -  data  link  menu  appears. 

2.  Press  numeric  key  0  -  ATARS  menu  appears. 

3.  Press  numeric  key  9  -  accesses  color  menu  (no  menu  appears). 

4.  Press  numeric  key  1. 

5.  Press  numeric  key  3. 

Threat  graphics  (feature  1)  will  now  be  drawn  in  light  blue  (color  3). 


Fig.  53.  ATARS  Parameter  Change  Examples  (2  of  2) 


Each  COMM-A  message  received  by  the  AID  is  automatically  printed  on  the 
onboard  printer.  The  fields  printed  per  message  are  the  ADS  code,  the  48  bit 
message  field,  and  the  scan  number.  By  checking  the  list  of  messages  against 
the  ones  that  were  expected,  the  operation  of  the  ATARS  ground  system,  data 
link  message  handler,  DABS  uplink  control,  and  air  link  can  be  examined.  The 
scan  number  is  set  by  the  AID  according  to  its  input  timing  rules,  and  thus 
proper  interrupt  and  timer  operation  can  be  checked  via  its  value  sequence. 

There  are  two  main  buffers  utilized  by  the  onboard  ATARS  software.  The 
first  is  the  input  buffer,  which  receives  a  field  unpacked  version  of  each 
ATARS  COMM-A.  If  its  messages  match  those  printed  by  the  printer,  message 
allocation  and  task  scheduling  have  performed  properly.  The  second  buffer  is 
the  display  buffer,  which  defines  the  picture  to  be  drawn  on  the  screen.  If 
it  has  the  proper  entries,  the  ATARS  correlation  and  tracking  software  must 
have  performed  properly. 

Knowledge  of  these  buffers  permits  non-real-time  playback  and  debugging 
of  the  ATARS  onboard  software.  If  the  first  is  correct,  but  errors  appear  in 
the  latter,  the  correlation  and  tracking  software  can  be  stepped  through  piece 
by  piece  once  the  input  buffer  has  been  manually  entered.  Similarly,  if  an 
inexplicable  display  ever  appears,  the  display  buffer  correlated  to  it  can  be 
entered  and  the  display  software  exercised  step  by  step. 

To  permit  these  tests,  a  full  RAM  is  dedicated  to  recording  the  two 
buffers.  It  can  be  printed  out  when  desired  as  described  below.  This  RAM  can 
hold  the  last  thirty  scans  on  which  ATARS  data  was  present.  Thus,  sufficient 
time  exists  for  a  real-time  problem  to  be  recognized,  several  scans  of  data 
viewed  to  identify  its  characteristics,  and  the  system  halted  without  any 
required  data  being  overwritten. 

Should  the  onboard  ATARS  system  enter  an  error  condition  or  an  infinite 
loop,  the  operator  can  enter  the  numeric  key  sequence  5-4-3-2-1.  This 
occurrence  halts  the  AID  and  causes  the  following  series  of  information  areas 
to  be  printed  on  the  printer: 

1.  Registers  (A-L,IX,IY),  stack  pointer,  and  program  counter 

2.  Computer  stack 

3.  Data  link  variables  and  buffers 

4.  ATARS  display  variables 

5.  ATARS  tracker  variables 

6.  ATARS  debug  RAM  (defined  above) 

From  some  or  all  of  this  data,  the  problem  can  hopefully  be  analyzed  and 
corrected.  If  some  of  the  data  is  not  required,  pressing  the  NO  key  will  skip 
the  printing  to  the  next  item  in  the  series.  Also,  if  NO  is  pressed  during 
the  printing  of  the  ATARS  debug  RAM,  the  system  will  be  restarted. 


9.0  ATARS  ONBOARD  SOFTWARE 


This  chapter  outlines  the  algorithms  and  procedures  that  constitute  the 
message  processing  and  display  creation  routines,  the  two  major  components  of 
the  ATARS  onboard  processing  system.  The  overall  system,  including  a 
description  of  the  context  within  which  these  routines  fit,  was  presented  in 
Chapter  7.  As  stated  there,  the  level  of  detail  to  be  provided  is  such  that 
all  the  complex  and  unusual  considerations  that  must  be  addressed  are 
covered.  Conversely,  no  attempt  will  be  made  to  fully  describe  the  obvious 
implementation  details  of  the  straightforward  segments  of  the  code. 

The  function  of  the  message  processing  software  is  to  combine  the  new 
information  contained  in  the  current  scan  COMM-A  messages  and  the  prior  scans' 
information  stored  in  the  various  internal  files  into  a  display  buffer  that 
describes  the  total  status  of  the  current  ATARS  scenario.  This  function 
should  be  nearly  identical  for  all  sophisticated  avionics.  Thus,  if 
programmed  carefully,  it  could  support  a  wide  range  of  display  devices,  and 
even  permit  "plug-in"  attachment  of  new  technology  displays  as  they  become 
available.  In  order  for  this  simplification  to  be  possible,  the  message 
processing  routine  must  be  the  entity  that  recognizes  and  overcomes  the 
effects  of  any  and  all  possible  errors  or  low  probability  events  in  the  ground 
or  air  segments  of  ATARS.  Then  all  complex  debug  operations  can  be  performed 
once  in  great  detail  and  be  dispensed  with. 

The  display  creation  routine  is  responsible  for  translating  the  ATARS 
scenario  described  in  the  display  buffer  into  a  visual  picture  (and/or  aural 
message)  for  the  pilot.  Almost  by  definition  this  routine  must  be  tailored  to 
the  specific  display  device.  However,  various  segments  of  the  code  will  be 
similar,  independent  of  the  device.  Thus,  by  presenting  the  software  details 
for  the  AID  display,  some  guidance  may  be  provided  to  designers  of  other 
display  systems. 

9. 1  Message  Processing  Software 

If  the  ATARS  ground  system  and  airlink  always  performed  perfectly,  the 
onboard  message  processing  system  would  be  extremely  simple.  Unfortunately, 
the  following  complications  can  be  expected  to  occur  from  time  to  time: 

1.  Two  (or  more)  sensors  send  ATARS  messages  to  the  aircraft  at  the  same 
time. 

2.  Some  messages  may  not  be  delivered  due  to  channel  time  constraints 
for  this  aircraft. 

3.  Missed  downlink  acknowledgements  result  in  duplicate  messages  being 
sent. 


The  second  and  third  of  these  are  not  too  difficult  to  overcome.  The  second 
forces  code  to  be  created  to  start,  coast,  and  end  encounters  in  the  absence 
of  the  proper  uplink  messages;  the  third  requires  all  messages  to  be  compared 
with  previously  received  ones. 

The  first  complication,  however,  leads  to  the  need  for  several  sections 
of  complex  software.  First,  the  two  sensors  may  well  employ  different  track 
numbers  for  the  same  encounter.  This  also  implies  that  the  same  track  nimber 
can  be  used  for  two  different  encounters  (one  by  each  sensor).  Thus,  a  full 
track-to-encounter  cross  reference  scheme  is  required.  Second,  the  messages 
from  the  two  sensors  may  arrive  during  the  same  time  period,  causing  the 
onboard  system  to  believe  they  have  all  arrived  from  one  sensor.  The 
algorithms  must  be  on  the  lookout  for  this  condition,  as  otherwise  numerous 
false  encounters  may  be  created  and  displayed.  Finally,  the  two  sensors  may 
disagree  on  the  most  critical  encounter:  since  two  most  critical  encounters 
would  interfere  with  proper  display  behavior,  arbitration  software  is 
required. 

Figure  54  is  a  flowchart  of  the  major  modules  in  the  onboard  message 
processing  system.  The  remainder  of  this  section  describes  each  box  in 
detail.  It  is  important  to  note  again  that  the  display  buffer  that  is 
produced  as  the  system  output,  whose  format  was  shown  in  Figures  33  and  34, 
can  be  employed  as  the  input  of  a  very  wide  range  of  display  devices.  Thus, 
it  is  possible  for  a  single  microcomputer  system,  coded  as  described  herein, 
to  serve  as  a  fixed  part  of  any  onboard  system.  As  cheaper  or  better  display 
avionics  are  developed,  a  simple  replacement  of  only  that  one  part  need  be 
effected. 


9.1.1  Preliminary  Processing 


ATARS  message  processing  can  proceed  only  when  all  messages  for  a  scan 
have  been  received.  This  group  processing  mode  is  required  for  two  reasons: 
(1)  ATARS  messages  are  not  independent,  as  in  various  situations  the 
information  for  an  encounter  will  be  contained  in  two  messages,  and  (2)  the 
order  in  which  the  messages  are  processed  can  affect  the  results.  An  example 
of  the  second  situation  is  that  proper  message-to-encounter  correlation 
requires  that  messages  with  track  numbers  (such  as  threat  or  single  prox)  be 
considered  before  those  without  track  numbers  (such  as  dual  prox). 

The  group  of  ATARS  messages  processed  together  is  called  a  packet.  As 
described  earlier  in  Section  7.2,  a  packet  is  ended  whenever  a  100  millisecond 
interval  occurs  after  receipt  of  the  previous  COMM-A  tnesssage.  This  time  is 
longer  than  the  aircraft  dwell  time  of  any  currently  envisioned  sensor 
antenna,  and  thus  its  having  elapsed  insures  that  no  more  messages  are 
forthcoming  this  scan.  However,  if  two  sensors  are  transmitting  ATARS 
advisories  to  the  aircraft,  and  their  dwell  times  overlap  (or  come  within  100 
milliseconds  of  each  other),  the  two  groups  of  messages  will  both  be  included 
in  the  same  packet.  The  current  software  attempts  to  detect  this  occurrence 
by  counting  the  number  of  most  critical  position  messages  contained  within  the 
packet.  Since  a  sensor  is  permitted  to  mark  only  one  such  message  per  scan  as 
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most  critical,  a  multiple  count  is  taken  as  proof  of  an  overlap.  When  sensor 
ID's  exist,  the  actual  separation  of  overlapping  packets  will  become  possible. 

The  preliminary  processing  routine  is  awakened  when  the  100  millisecond 
timeout  signal  is  triggered.  The  processing  initiation  is  delayed,  however, 
if  other  tasks  are  still  in  execution.  Thus,  it  is  possible  that  messages 
from  the  next  packet  will  have  arrived  by  the  time  the  processing  begins, 
particularly  if  multiple  sensors  are  uplinking  information.  However,  only 
messages  for  the  first  packet  are  processed  in  the  first  program  pass;  the 
subsequent  packet,  if  completely  received  by  the  end  of  this  pass,  is  then 
processed  immediately  in  a  second  pass  through  the  software.  Only  then  is 
control  returned  to  other  tasks.  In  particular,  no  display  will  be  generated 
until  both  packets  have  been  processed.  This  guarantees  that  the  most  current 
display  will  be  shown  as  quickly  as  possible. 

Once  all  messages  in  the  packet  are  identified,  a  search  is  made  for 
duplicate  messages  by  a  simple  pairwise  comparison.  The  number  of  most 
critical  position  messages  remaining  is  then  counted;  if  greater  than  one, 
overlapped  data  from  two  sensors  has  probably  occurred  and  correlation  must  be 
more  complex,  as  described  below. 

The  next  step  is  to  pair  messages  when  two  exist  for  the  same  encounter. 
Two  types  of  pairings  are  possible: 

1.  A  start  threat  message  with  a  threat  message  whose  first  time 
threat  bit  is  set  -  the  messages  will  have  the  same  track  number. 

2.  A  half  of  a  dual  prox  message  having  its  most  critical  bit  set  with 
the  supplementary  part  of  an  own  plus  supplementary  message  -  each 
must  be  unique  within  the  packet. 

The  final  part  of  preliminary  processing  is  sorting  the  ATARS  messages 
into  5  classes  of  priority,  ordered  as  follows: 

1.  own  messages 

2.  threat  messages 

3.  single  proximity  messages  (and  dual/supplementary  pairs) 

4.  dual  proximity  messages 

5.  resolution  messages 

Own  messages  have  highest  priority  because  the  current  own  aircraft 
heading  and  turn  rate  are  needed  for  correlation  of  other  messages  to  their 
corresponding  encounters.  Threat  messages,  being  more  critical  than 
proximity  ones,  are  treated  next  to  provide  a  higher  likelihood  of  proper 
correlation.  Since  dual  proximity  messages  contain  no  track  numbers  to  use 
for  correlation,  it  is  important  that  they  be  processed  after  all  encounter 
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messages  with  track  numbers;  only  then  will  the  set  of  "leftover  encounters" 
be  known.  Finally,  resolution  messages  are  totally  independent  of  all  others, 
and  can  be  processed  at  any  time. 

9.1.2  Encounter  Processing 

The  encounter  processing  routine  is  responsible  for  updating  the  position 
and  status  of  all  active  encounters.  It  performs  this  mission  in  three  parts. 
First  it  correlates  the  newly  received  ATARS  messages  with  the  encounters 
existing  from  the  previous  scan.  Then,  whenever  a  failure  results,  a  new 
encounter  file  is  opened.  Finally,  it  updates  the  information  in  each 
encounter  file  from  the  fields  of  the  new  messages.  In  addition,  if  any 
threat  encounters  exist,  it  computes  the  closest  point  of  approach  data  for 
them. 

The  correlation  procedure  complexity  depends  upon  whether  or  not  the 
onboard  computer  believes  ATARS  to  be  in  its  "normal"  condition,  which  is  that 
messages  are  being  transmitted  by  a  single  sensor.  The  set  of  checks  that 
must  be  satisfied  for  normality  to  hold  when  no  sensor  ID’s  exist  is: 

1.  The  last  three  own  messages  have  their  seam  bit  set  to  zero 
(indicating  single  coverage). 

2.  Only  one  most  critical  message  exists  in  the  current  packet. 

3.  No  encounter  is  being  updated  by  two  or  more  track  numbers. 

4.  No  track  number  is  being  used  to  update  two  or  more  encounters. 

The  first  condition  would  be  sufficient  if  perfect  ground  coordination  could 
be  assumed.  The  third  and  fourth  conditions  could  be  caused  by  previous 
onboard  correlation  errors  as  well  as  by  multiple  coverage;  whatever  the 
cause,  however,  more  complex  correlation  logic  would  be  needed. 

Figure  55  presents  the  overall  correlation  flowchart.  The  usual 
correlation  mechanism  between  ATARS  message  and  encounter  file  is  the 
ground-assigned  track  number.  Thus,  if  no  number  exists,  such  as  for  a  dual 
proximity  message,  a  more  complex  comparison  of  position  attributes  between 
message  and  encounter  file  must  be  undertaken.  The  description  of  this 
matching  process  is  presented  below. 

Normally,  only  encounters  not  yet  updated  by  a  message  in  the  current 
packet  are  permitted  to  enter  into  such  correlation  processes.  However,  if 
messages  from  two  or  more  sensors  are  thought  to  be  contained  in  this  packet, 
as  signalled  by  more  than  one  message  with  its  most  critical  bit  set,  this 
rule  must  be  waived;  each  encounter  may  then  be  updated  once  by  each  sensor. 
Sensor  ID  bits  would  be  very  useful  in  these  situations  to  prevent  an 
encounter  from  being  erroneously  updated  by  two  messages  from  one  sensor, 
instead  of  by  one  from  each. 
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Fig.  55.  Message-to-Encounter  Correlation  Flowchart. 
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Should  a  match  be  discovered,  the  dual  proximity  message  is  assigned  to 
that  encounter.  No  attempt  to  find  the  "best”  match  is  made  should  two 
encounters  be  acceptable,  as  the  data  quality  is  too  poor  to  support  a  complex 
scoring  mechanism;  instead,  the  search  ends  with  the  first  match.  No  serious 
harm  could  result  from  an  improper  cross  correlation.  In  the  worst  case, 
depicted  in  Fig.  56,  an  extra  proximity  will  appear  on  the  screen  for  one 
scan. 


If  no  match  is  discovered  for  the  dual  proximity  message,  it  is 
discarded,  as  no  new  encounter  can  be  initiated  without  a  track  number.  As 
long  as  proximity  start  messages  with  their  track  numbers  are  repeated  each 
scan  until  a  downlink  acknowledgement  is  received,  as  is  assumed,  the 
condition  of  uncorrelated  dual  proximity  messages  should  not  arise.  Even  if  it 
does,  the  loss  of  the  encounter  cannot  be  critical:  should  the  encounter 
transition  to  a  threat  status,  the  threat  messages  transmitted  for  it  will 
contain  a  track  number,  and  the  encounter  file  will  then  be  opened. 

When  the  ATARS  message  contains  a  track  number,  such  as  threat  or  single 
proximity  messages,  and  the  ATARS  system  is  in  its  "normal”  state  as  defined 
above,  the  message  to  encounter  correlation  is  obtained  directly  from  the 
cross  reference  array  entry.  If  this  entry  is  null,  a  new  encounter  file  is 
opened,  while  if  it  contains  an  encounter  number,  that  file  is  the  one  to 
update.  One  complication  arises  when  an  entry  exists  but  the  ATARS  message 
indicates  the  start  of  a  new  encounter.  This  situation  arises,  as  discussed 
in  section  4.3,  when  the  ground  sensor  had  more  than  eight  encounters  and  thus 
does  not  have  track  numbers  available  for  all  of  them.  In  such  a  case,  a  new 
encounter  may  be  assigned  a  number  previously  assigned  to  another  one  without 
that  latter  one  being  terminated  by  an  end  message.  Thus,  the  proper  onboard 
action  when  this  situation  is  encountered,  as  shown  in  the  flowchart,  is  to 
initiate  a  new  encounter  file.  The  old  one,  when  not  updated,  will  be 
dropped. 

Should  ATARS  not  be  In  a  normal  state,  however,  no  correlation  can  be 
accepted  without  the  comparison  of  position  attributes  described  below.  This 
is  because  a  track  number  can  be  used  for  different  encounters  by  different 
sensors.  Should  one  or  more  encounter  currently  exist  for  the  track  number, 
as  shown  by  the  cross  reference  array,  one  of  these  will  probably  be  the 
proper  one.  Thus,  these  encounters  are  tested  first  for  a  match  conditio;.. 

If  all  such  encounters  fail  the  test,  or  if  no  encounters  were  listed  for  the 
track  number,  every  existing  encounter  is  tested  for  a  successful  match.  If 
still  only  failure  results,  a  uew  encounter  file  is  initiated.  As  for  the 
dual  proximity  case,  the  first  successful  match  is  accepted,  as  no  method  for 
choosing  between  matches  could  be  supported  by  the  quality  of  data  in  the 
ATARS  message.  This  could  conceivably  result  in  a  wrong  correlation,  although 
the  existence  of  track  numbers  in  the  messages  makes  this  an  extremely  remote 
chance. 
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Correct  Actions  are: 

Message  Mi  updates  Encounter  Ei 
Message  tl2  upda.es  Encounter  E2 


However,  with  "first  success"  rule,  if  Mj  first  attempts  to  correlate  with  E2, 
the  results  will  be: 

Message  Mi  correlates  with  and  updates  Encounter  E2 
Message  M2  fails  to  correlate  with  Encounter  Ei  and  thus  initiates 
new  Encounter  E3 
Encounter  Ei  is  coasted 


and  3  proximities  instead  of  2  will  appear  on  the  screen  this  scan. 


Fig.  56.  Correlation  Failure  Example. 
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The  matching  algorithm  employed  for  correlation  checks  three  position 
attributes:  relative  altitude,  range,  and  relative  bearing.  In  each  case, 
these  quantities  in  the  encounter  file  are  projected  forward  one  scan,  using 
the  encounter  file  rates,  to  the  current  time,  and  then  compared  with  the 
corresponding  quantities  in  the  new  ATARS  message.  Two  boxes  are  defined 
around  each  projected  position  attribute,  a  small  one  and  a  large  one.  If  the 
message  quantity  falls  within  the  smaller  box,  the  correlation  score  (which 
starts  at  0)  is  not  changed;  if  within  the  larger  box,  the  score  is 
incremented  by  1;  if  outside  both  boxes,  the  correlation  is  rejected.  A  match 
is  said  to  have  occurred  if  no  attribute  results  in  rejection  and  the  final 
score  is  no  greater  than  2.  This  implies  that  a  tight  match  on  at  least  one 
attribute,  and  reasonable  matches  on  the  others,  is  required  for  correlation. 

Four  special  situations  must  be  considered  in  this  matching  algorithm. 
First,  if  the  encounter  is  a  new  one,  the  encounter  file  rates  will  not  yet 
exist.  In  this  case,  the  own  turn  rate  provides  the  best  guess  as  to  the 
bearing  rate,  being  its  main  component,  and  the  encounter’s  vertical  speed  (if 
known)  provides  an  estimate  of  the  altitude  rate.  Since  no  such  range  rate 
estimate  exists,  the  predicted  range  must  be  set  equal  to  the  current  range 
for  new  encounters.  Second,  because  this  resulting  predicted  position  is  less 
accurate  for  new  encounters,  the  correlation  boxes  muse  be  made  larger  for 
them.  Third,  although  the  bearing  boxes  are  generally  defined  in  degrees, 
they  cannot  be  allowed  to  shrink  smaller  in  miles  than  the  range  boxes  for 
close-in  encounters. 

Finally,  both  larger  altitude  boxes  and  special  case  recognition  is 
required  for  encounters  beyond  2000'  in  relative  altitude.  The  former 
reflects  the  coarser  level  of  altitude  specification  (namely  500*  lsb)  in  this 
area,  while  the  latter  reflects  the  fact  that  either  the  message  or  the 
encounter  file  may  be  missing  the  altitude  extension  field.  Thus  a  relative 
altitude  of  2000’  in  either  the  message  or  the  file  must  be  considered  as 
matching  any  larger  value  in  the  other. 

Once  the  correlating  encounter  for  the  new  ATAP.S  message  is  determined, 
any  alterations  to  the  cross  reference  array  (depicted  in  Figure  32)  that  this 
match  necessitates  are  made.  The  following  are  the  cases  requiring  come 
action: 

1.  The  message  was  an  end  message  -  the  cross  reference  entry  is 
removed;  if  the  encounter  is  no  longer  supported  by  any  track  number, 
it  is  dropped. 

2.  The  message  track  number  is  a  new  one  for  the  encounter  -  a  new  cross 
reference  entry  is  created,  and  the  encounter  is  now  supported  by  an 
additional  track  number. 

3.  A  new  encounter  was  Initiated  -  the  new  cross  reference  entry  is 
created. 
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In  the  normal  single  sensor  environment,  an  end  message  causes  the  encounter 
to  be  dropped,  and  no  encounter  will  ever  be  supported  by  two  track  numbers. 

The  updating  of  the  various  ATARS  files  from  the  new  scan's  messages  is 
fairly  straightforward.  The  descriptions  of  the  fields  in  these  files 
provided  in  section  7.3  indicated  the  manner  in  which  each  is  determined. 

Thus,  only  a  few  more  notes  are  warranted  in  this  section. 

If  an  own  or  resolution  message  is  present,  the  own  file  is  updated  prior 
to  the  above  correlation  actions.  This  permits  the  most  current  own  data  to 
be  employed  in  the  correlation  tests.  When  all  message-to-encounter 
correlations  are  completed,  each  active  encounter  file  is  brought  up  to  date 
by  any  message  or  messages  correlated  to  it.  Then  messages  for  which  no 
encounter  files  previously  existed  are  used  to  create  new  encounter  files. 

For  each  threat  encounter,  a  check  is  made  to  determine  whether  the 
closest  point  of  approach  calculations  described  in  the  Appendix  can  be  made. 
The  three  conditions  that  must  be  satisfied  for  these  equations  to  be  relevant 
are: 

1.  the  encounter  is  not  newly  initiated  on  the  current  scan  -  if  so,  no 
positional  rates  will  yet  exist 

2.  the  current  range  is  greater  than  the  miss  distance  -  if  not,  the 
data  is  not  consistent 

3.  the  relative  range  rate  of  the  aircraft  is  negative  -  if  not,  the 
calculated  quantities  will  be  meaningless. 

9.1.3  Display  Buffer  Preparation 

Once  all  the  ATARS  files  have  been  updated,  the  total  current  ATARS 
scenario  can  be  constructed.  The  display  buffer,  whose  format  was  described 
in  Figures  33  and  34,  is  the  vehicle  used  to  transmit  this  snapshot  to  the 
display  drawing  software.  As  part  of  this  buffer  preparation  process,  two 
auxiliary  functions  are  performed.  The  first  is  the  elimination  of  timed-out 
encounters,  namely  those  not  updated  by  the  ground  for  two  successive  scans. 
The  second  is  the  verification  of  the  most  critical  encounter  logic.  As 
explained  in  section  7.3,  several  anomalous  events  can  cause  no  or  several 
encounters  being  so  labelled  instead  of  the  mandated  single  one. 

The  posicions  of  encounters  not  updated  on  the  current  scan  must  be 
coasted  before  being  entered  into  the  display  buffer.  If  the  encounter  has 
been  updated  at  least  once  since  its  initiation,  the  range,  bearing,  and 
altitude  rates  to  apply  are  resident  in  the  encounter  file.  Otherwise,  the 
latter  two  rates  can  only  be  inferred  in  a  gross  sense,  while  no  range  rate 
estimate  at  all  can  be  made.  The  largest  bearing  change  component  is  due  to 
own  aircraft  turns.  Since  own  turn  rate  is  known,  this  correction  component 
can  be  computed  for  new  encounters.  Similarly,  the  vertical  speed  of  the 
other  aircraft,  if  provided,  can  be  used  to  update  the  estimate  of  the  current 
altitude  difference. 
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The  time  interval  for  a  coast  action  is  the  difference  between  the 
current  time  and  the  last  update  time  stored  in  the  encounter  file.  If  this 
interval  exceeds  1  1/2  scans,  the  encounter  is  dropped  and  not  entered  into 
the  display  buffer.  The  encounter  cross  reference  array  is  then  adjusced  to 
reflect  this  loss. 

After  the  status  of  each  encounter  has  been  updated,  a  count  is  made  of 
the  number  labelled  most  critical.  Depending  upon  the  result,  one  of  the 
paths  presented  in  the  flowchart  of  Figure  57  is  logically  followed.  Only 
the  path  for  a  result  of  one  represents  proper  behavior. 

However,  as  shown  in  the  flowchart,  even  with  this  result  an  anomaly 
could  have  occurred.  In  particular,  if  the  most  critical  encounter  is  a 
proximity,  and  yet  a  threat  encounter  exists,  the  outcome  is  inconsistent.  If 
the  threat  was  not  updated  on  the  current  scan,  then  the  only  logical 
conclusion  (assuming  no  ground  error)  is  that  the  encounter  had  transitioned 
to  proximity  status  (or  even  disappeared)  and  the  uplink  message  confirming 
the  event  was  not  received.  Thus,  the  onboard  processor  will  be  acting 
properly  by  converting  the  encounter  out  of  threat  status  as  shown  in  the 
flowchart.  If  the  threat  encounter  was  updated,  though,  an  unexplainable 
situation  exists.  The  best  the  onboard  processor  can  do  in  this  case  is  to 
set  the  most  time-critical  threat  to  be  the  most  critical  encounter,  and 
remove  that  label  from  the  proximity. 

Whenever  none  or  several  most  critical  encounters  exist,  the  onboard 
processor  must  select  one  encounter  to  be  so  labelled  for  the  display.  To  aid 
in  this  decision  process,  the  encounter  set  is  partitioned  into  the  eight 
possible  subsets  corresponding  to  the  states  of  three  binary  parameters: 
threat  or  proximity,  updated  or  coasted,  most  critically  labelled  or  not. 
Within  each  subset  the  most  dangerous  encounter  is  found,  with  time  to  CPA  and 
range  being  the  criteria  for  threat  and  proximity  encounters  respectively. 

The  eight  "winners"  are  then  denoted  as  follows: 

MCUT  -  most  critical  updated  threat  winner 
MCCT  -  most  critical  coasted  threat  winner 
MCUP  -  most  critical  updated  proximity  winner 
MCCP  -  most  critical  coasted  proximity  winner 
NCUT  -  non-critical  updated  threat  winner 
NCCT  -  non-critical  coasted  threat  winner 
NCUP  -  non-critical  updated  proximity  winner 
NCCP  -  non-critical  coasted  proximity  winner 

Of  course,  any  of  the  subsets  could  be  null,  as  would  then  be  its  winner. 

If  no  most  critical  encounters  exist,  the  first  four  subsets  must  be 
null,  and  so  the  encounter  to  be  labelled  most  critical  could  only  be  one  of 
the  latter  four  winners.  The  most  likely  explanation  for  the  absence  of  a 
most  critical  encounter  is  that  its  uplink  message  was  not  received.  Thus,  if 
a  coasted  threat  exists,  it  may  well  have  been  the  one  set  most  critical  by 
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Fig.  57.  Most  Critical  Encounter  Logic  (2  of  2), 


the  ground.  This  accounts  for  NCCT  being  the  first  choice  if  not  null. 
Similarly,  NCCP  is  chosen  before  NCUP  if  no  threats  exists.  The  only  anomaly 
occurs  if  an  updated  threat  and  a  coasted  proximity,  NCUT  and  NCCP,  are  in 
competition.  Clearly,  the  ground  could  have  converted  this  proximity  to  a 
threat  and  labelled  it  most  critical.  However,  the  decision  was  made  at 
Lincoln  not  to  "create"  threat  encounters  in  the  onboard  processor  in  the 
absence  of  information.  Thus  the  known  threat  encounter  NCUT  is  set  most 
critical. 


Finally,  if  several  most  critical  encounters  exist,  any  or  all  of  the 
eight  subsets  could  be  populated,  and  hence  the  selection  rules  become  more 
complex  in  this  case.  The  details  of  the  algorithm  specifying  the  competition 
among  the  winners  is  given  by  the  flowchart.  Clearly,  if  a  most  critical 
updated  threat  exists,  it  must  be  selected.  However,  a  non-critical  updated 
threat  will  be  beaten  by  either  type  of  coasted  threat  according  to  the  logic 
presented  above.  If  no  updated  threat  of  either  type  exists,  a  most  critical 
updated  proximity  takes  precedence  over  a  coasted  threat.  As  discussed  under 
the  case  of  one  most  critical  encounter,  all  such  coasted  threats  are 
converted  to  proximity  status  by  implication  of  the  ground  actions.  Finally, 
the  remainder  of  the  selection  process  reflects  the  decision  never  to  upgrade 
a  proximity  to  a  threat  without  ground  notification. 


Once  these  preliminaries  are  out  of  the  way,  the  actual  creation  of  the 
display  buffer  can  commence.  The  manner  in  which  each  of  its  entry  fields  is 
filled  from  the  encounter  files  follows  from  the  discussion  of  section  7.3  and 
so  no  further  details  will  he  provided  here. 

The  display  buffer  header  fields  come  from  the  own  file,  from  the  screen 
parameter  values  as  set  by  the  operator,  and  from  an  active  encounter  count 
maintained  by  the  buffer  creation  code.  Two  special  actions  are  required 
during  the  header  formation.  First,  a  check  must  be  made  whenever  a 
resolution  advisory  exists  as  to  its  last  update  time.  If  16  or  more  seconds 
have  elapsed,  the  advisory  has  timed  out,  and  it  must  be  removed  from  the 
display.  This  action  is  performed  by  zeroing  the  resolution  fields  and 
setting  the  first  time  resolution  bit  to  signal  the  state  change.  The  other 
special  action  is  setting  the  3-second  bit  of  the  header  whenver  less  than  3 
seconds  have  elapsed  since  the  last  display  buffer  was  presented  to  the 
display.  Many  displays,  including  the  AID,  can  not  be  updated  faster  than 
every  3  seconds  without  compromising  pilot  comprehension. 

9.2  Display  Creation  Software 

The  display  creation  software,  in  comparison  with  the  code  just 
described,  is  fairly  straightforward  and  free  of  special  cases.  Its  only 
input  is  a  display  buffer  with  a  guaranteed  format,  and  thus  it  is  insulated 
from  any  errors  or  unusual  cases  produced  by  the  ground  or  airlink  parts  of 
the  ATARS  system.  A  flowchart  of  this  routine  is  provided  by  Figure  58. 
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Fig.  58.  Display  Creation  Logic  (2  of  2). 
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If  the  new  display  buffer  is  less  than  3  seconds  more  current  than  the 
existing  ATARS  display,  it  is  discarded  and  the  present  picture  left  on  the 
screen.  This  rule  provides  the  pilot  with  sufficient  time  to  absorb  a  display 
before  it  is  replaced.  Otherwise,  if  ATARS  is  on  the  screen,  its  display  area 
is  cleared  in  preparation  for  the  construction  of  the  new  scan's  display.  Any 
tactical  message  residing  at  the  top  of  the  display  (see  Figure  27)  is  kept, 
however. 

If  ATARS  is  not  currently  being  displayed,  a  determination  must  be  made 
as  to  whether  its  priority  is  sufficiently  high  to  replace  the  current  screen 
user  (data  link,  weather)  if  any.  If  the  ATARS  scenario  includes  a  resolution 
or  threat  advisory,  it  is  automatically  the  highest  priority  user.  Otherwise, 
if  only  proximities  exist,  the  priority  set  by  the  proximity  priority 
parameter  determines  the  screen  use.  Section  7.2  discussed  this  issue  in 
detail.  Finally,  if  no  ATARS  advisory  of  any  type  exists,  no  ATARS  display  is 
generated. 

Two  types  of  ATARS  displays  have  been  defined.  If  the  screen  level 
parameter  is  set  to  0,  only  a  resolution  string  is  desired.  With  any  other 
level  setting,  a  graphical  picture  in  addition  is  sought.  With  no  encounters 
present,  of  course,  the  latter  type  degenerates  to  the  former  one. 

The  first  action  that  must  be  performed  when  a  graphic  display  is  desired 
is  the  determination  of  the  screen  range  setting.  If  the  RNG  parameter  is  in 
a  manual  mode  (refer  to  section  8.2.1),  its  value  specifies  the  range  setting. 
Otherwise,  the  display  software  must  calculate  the  proper  value  from  the 
locations  of  the  encounters  included  within  the  guaranteed  to  be  on  screen 
subset  (all,  threats,  or  most  critical).  The  procedure  is  to  process  each 
such  encounter  as  follows: 

1.  read  its  bearing; 

2.  compute  the  screen  expansion  factor  for  that  bearing 
(such  as  1.0  at  90°,  2.0  at  0°,  1.4  at  135°,  or  2.2  at 
45°)  due  to  the  rectangular  shape  of  the  display  region; 

3.  divide  its  range  by  this  factor. 

The  proper  screen  range  setting  is  then  the  largest  value  found  in  any 
encounter’s  step  3,  rounded  up  to  an  integer,  with  a  minimum  setting  of  2 
miles. 

Once  the  screen  scale  factor  is  known,  the  fixed  parts  of  the  display  can 
be  generated.  These  are  the  two  mile  range  ring,  the  own  aircraft  vector,  the 
parameter  values  if  the  level  parameter  is  9,  and  the  resolution  string,  if 
any.  Three  lines  are  reserved  for  resolution  advisories.  The  only  time  that 
this  value  is  insufficient  is  if  two  positive/neg.  tive  resolutions  and  a 
vertical  speed  limit  resolution  all  exist  at  once,  such  as: 
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NO  RGT  (don't  turn  right) 

NO  LFT  (don't  turn  left) 

LM  CLI  (limit  climb  to 

1000  1000'  per  minute) 

In  this  case,  the  fourth  line  will  not  appear.  Its  importance,  though,  is 
much  less  than  any  of  the  other  three. 

The  remainder  of  the  display  code  generates  the  presentation  of  the 
information  for  the  active  encounter  set.  Whenever  one  or  more  threat  exists, 
the  first  encounter  processed  is  the  most  critical  threat,  identified  by 
having  its  most  critical  bit  set.  First  its  position  symbol,  heading  vector, 
and  altitude  alphanumerics  are  drawn  at  its  relative  location.  Then,  if  the 

level  parameter  is  set  to  3  or  greater,  the  closest  point  of  approach  and 

relative  motion  line  details  are  drawn. 

The  relative  motion  line  extends  from  the  current  position  symbol  to  the 
CPA  position  X.  This  line  is  drawn  dot  by  dot  on  the  screen  along  the 
calculated  slope.  Each  time  10  seconds  worth  of  dots  have  been  drawn,  a 
perpendicular  tick  mark  is  constructed.  These  marks  are  skipped,  however,  if 
the  current  position  is  off-screen.  A  line  is  still  drawn  from  the  triangle 
position  symbol  to  the  X,  even  though  its  slope  will  not  be  quite  correct. 

This  effect  is  illustrated  by  Figure  59. 

Since  the  time  to  CPA  is  written  in  a  sidebar  area,  one  of  the  two 
possible  sidebar  areas  must  be  chosen.  The  rules  specifying  this  selection 
are: 

1.  if  the  time  to  CPA  was  shown  last  scan,  use  the  same 
side  again 

2.  if  this  is  the  first  presentation  of  time  to  CPA,  choose 
the  side  nearer  the  position  of  the  threat 

The  first  rule  allows  the  pilot  to  concentrate  on  the  time  to  CPA  values  as 
they  proceed  through  their  time  sequence  without  having  to  jump  his  viewpoint 
from  side  to  side.  The  aircraft  information  data,  if  applicable  to  the  level, 
is  written  in  the  same  sidebar. 

Other  threats,  if  any,  are  processed  next.  Each  has  its  position  symbol, 
heading  vector,  and  altitude  alphanumerics  drawn  provided  the  location  is 
within  the  screen  boundaries.  If  not,  a  triangle  is  drawn  on  the  screen 
boundary  at  the  proper  bearing.  In  addition,  if  the  level  parameter  is  set  to 
4,6,8  or  9,  the  closest  approach  position  and  associated  data  is  drawn  for  the 
second  threat.  No  algorithm  is  provided  for  selecting  this  second  threat  when 
more  than  two  threats  exist;  the  one  earliest  in  the  display  buffer  wins. 

This  random  selection  rule  is  justified  simply  by  the  expectation  that  three 
threats  will  probably  never  occur  at  once.  The  second  threat  time  to  CPA,  and 
aircraft  information  if  necessary,  are  placed  in  the  remaining  sidebar  area  of 
the  display. 
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Fie.  59.  Relative  Motion  Line  for  Off-Screen  Threats 


Finally  the  proximity  encounters,  if  any,  are  processed.  If  no  threats 
exist,  and  the  proximity  display  mode  is  "point/none",  no  representation  of 
proximity  encounters  is  desired.  Otherwise,  either  a  full  symbol  plus  vector 
plus  alphanumeric  format,  or  a  point  symbol  format,  is  provided  for  each. 
Again,  only  a  triangle  is  drawn  for  any  off-screen  encounter.  Also,  any 
encounter  just  within  the  screen  boundary,  but  whose  heading  vector  extends 
beyond  it,  is  drawn  without  this  vector.  Its  absence  at  least  informs  the 
pilot  of  the  encounter's  positive  range  rate. 


. . . . . . . . . . . . 


APPENDIX 


ATARS  Closest  Point  of  Approach  (CPA)  Calculations 


Overview 


The  full  information  display  of  the  Lincoln  designed  ATARS  onboard  system 
specifies  the  parameters  of  a  threat  encounter  in  the  manner  depicted  in 
Fig.  Al.  The  heart  of  this  picture  is  the  relative  motion  vector  from  the 
threat  aircraft's  current  position  to  its  predicted  closest  point  of  approach. 
The  time  until  this  near-miss  point  is  attained  is  also  specified,  both  as 
tick  marks  on  the  vector  and  as  a  number  on  the  side  of  the  screen. 

The  current  version  of  the  ATARS  message  formats  does  not  provide  all  the 
information  needed  to  create  this  display.  In  particular,  of  the  four 
quantities  needed  for  the  picture  shown  in  Fig.  Al: 

1.  Miss  distance 

2.  Miss  bearing 

3.  Miss  altitude 

4.  Time  to  closest  approach 

only  the  first  is  supplied  by  the  ground  sensor.  Thus,  the  latter  three  must 
be  computed  in  the  onboard  computer. 

In  order  not  to  overtax  the  microcomputer  in  the  onboard  ATARS  system, 
the  calculations  of  these  quantities  must  be  fairly  simple,  and  not  contain 
complex  mathematical  functions  (such  as  square  root).  This  appendix  develops 
formulas  that  meet  this  restriction. 

This  appendix  also  investigates  the  effect  of  the  truncated  data  accuracy 
in  the  uplink  messages  on  the  time  of  closest  approach  calculation.  As  this 
quantity  is  most  sensitive  to  data  variations,  the  equation,  although  exact, 
could  yield  an  erroneous  result  when  computed  onboard.  Of  course,  the  ground 
tracker  itself  could  have  computed  incorrect  data  values,  particularly 
aircraft  headings.  The  effects  of  these  errors  on  the  time  to  closest 
approach  is  also  studied. 

Exact  Formulas 

The  underlying  geometry  for  the  closest  approach  calculations  is 
presented  in  Fig.  A2.  The  known  quantities,  from  uplink  messages,  are  the 
following: 

1. -  Current  range  to  threat,  p 

2.  Current  relative  bearing  of  threat,  0 

3.  Current  relative  heading  of  threat,  h 

4.  Current  velocity  of  threat,  v 
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5.  Current  relative  altitude. of  threat,  z 

6.  Altitude  rate  of  threat,  zt 

7.  Current  own  speed,  s 

8.  Current  own  heading,  hQ 

9.  Predicted  miss  distance,  m 

Also,  it  is  assumed. that  onboard  instruments  tied  into  ATARS  can  provide  the 
own  altitude  rate,  zQ. 

Since  the  miss  distance  must  be  perpendicular  to  the  relative  motion 
line,  the  angle  8,  which  is  the  difference  between  the  current  and  closest 
approach  bearings  (see  Fig.  A2),  is  given  simply  by: 


8  =  cos~l(ra/p) 


(1) 


However,  since  the  miss  point  could  be  on  either  side  of  the  current  bearing, 
a  determination  must  be  made  as  to  the  sign  of  8,  i.e.: 


Bm  =  miss  bearing  =  B  ±  8 

This  determination  is  made  by  computing  the  heading  of  the  threat  aircraft’s 
relative  motion  vector: 


relative  x  motion 

hrej  =  tan~l  - 

relative  y  motion 

v  sin  h 

hrei  =  tan  ^  (2) 

v  cos  h-s 


Then,  if  the  relative  heading  is  to  the  "right"  of  the  current  bearing,  8  is 
added,  or  if  to  the  "left",  8  is  subtracted.  Mathematically,  this  can  be 
expressed  by: 
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where  continuous  subtraction  at  360°  is  required 
(i.e. :  150°  -  350°  =  160°). 


The  most  direct  formula  for  the  time  until  closest  approach  is  given  by 
the  ratio  of  the  distance  along  the  relative  motion  line  and  the  velocity 
along  this  line,  which  is  of  course  the  relative  velocity  of  the  threat 
aircraft.  Thus,  referring  to  Fig.  A2: 


vrel 


p  sin  0 

J(v  sin  h)2  +  (v  cos  h  -  s)2 


(3) 


Finally,  once  t  is  known,  the  relative  altitude  of  the  threat  aircraft  at 
the  closest  point  of  approach  is  given  simply  as: 


z  +  (zc-  zG)  T 


(4) 


Simplified  Formulas 


The  previous  section  has  demonstrated  that  an  onboard  computer  has 
sufficient  information  to  compute  all  required  closest  approach  quantities. 
However,  to  do  so  it  must  be  capable  of  performing  all  the  mathematical 
functions  contained  in  equations  (1)  -  (4),  namely  arccosine,  arctangent, 
sine,  cosine,  and  square  root.  Most  microcomputers  are  incapable  of  this 
level  of  mathematical  sophistication  unless  a  table  lookup  procedure  were 
employed.  Sven  with  this  approach,  the  arctangent  and  square  root 
calculations  would  be  quite  complex  and  time  consuming.  . 

By  only  requiring  the  calculation  of  a  threat's  closest  point  of  approach 
on  the  second  and  subsequent  scans  of  an  encounter  (implies  first  threat  scan 
is  permissable  for  an  encounter  beginning  as  a  proximity),  a  decided 
simplification  of  the  mathematics  results.  With  two  or  more  scans  of  data 
available,  the  bearing,  range,  and  altitude  rates  of  the  threat  aircraft  can 
be  computed: 
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[new  0  -  0  (n  scans  ago)]  +  [new  h0  -  h0  (n  scans  ago)] 
n  *  scan  rate 

where  second  term  removes  effects  of  own  turn 
new  p  -  p  (n  scans  ago) 
n  *  scan  rate 


new  z  -  z(n  scans  ago) 


n  *  scan  rate 


The  value  of  n  should  be  small,  to  detect  changes  in  aircraft  headings  or 
climbs,  yet  large  enough  to  allow  some  averaging;  probably  n  =  2  is  best.  Of 
course  only  n  =  1  is  possible  for  the  second  scan  of  an  encounter. 


Once  0  is  known,  its  sign  provides  the  direction  of  movement  of  the 
threat  aircraft,  and  hence  the  direction  of  the  closest  bearing  point  relative 
to  the  current  one  (under  the  usual  linear  motion  assumption).  Thus,  (2)  and 
(2’)  can  be  replaced  by: 


if  0  >  0,  0m  -  0  +  0 

<5) 

if  B  <  0,  Bm  «  3  “  6 

and  the  difficult  arctangent  function  is  no  longer  required. 

Similarly,  by  knowing  p,  formula  (3)  can  be  simplified  by  relating  the 
relative  motion  velocity  to  its  projection  along  the  current  bearing  line: 

p  =  vrex  sin  0 

thereby  reducing  the  result  to: 


p  sin  6 


p/sin  9 


t  =  -  sin^  0 
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This  removes  the  other  complex  function,  the  square  root. 

Finally,  the  value  of  z  can  be  used  directly  to  compute  altitude  at 
closest  approach: 

zm  =  z  +  z  t  (7) 

Thus,  the  assumption  that  own  climb  rate  is  supplied  by  a  tie-in  between 
onboard  instruments  and  ATARS  is  no  longer  required. 

Improved  t  Formula 

The  rates  computed  in  the  previous  section  are  all  subject  to  large 
errors  because  of  the  data  truncation  employed  by  the  uplink  messages. 
Specifically,  the  least  significant  bits  in  the  measurements  are: 

0:  3.75° 

p :  0.2  miles 

z:  100  feet 

Thus,  large  fluctuations  in  scan  to  scan  rates  are  to  be  expected. 

Furthermore,  if  any  threat  aircraft:  measurement  changes  sufficiently  slowly, 
the  same  value  wi'.l  be  reported  on  consecutive  scans,  leading  to  a  computed 
zero  rate. 

Since  only  the  sign  of  S  is  used  in  the  0ra  computations,  fluctuations  are 
irrelevant.  Also,  if  a  zero  value  is  determined,  the  value  of  0  must  be  very 
small,  so  using  addition  or  subtraction  will  make  a  minor  difference, 
imperceivable  on  the  display. 

Similarly,  any  possible  fluctuations  in  z,  especially  with  a  two  scan 
average,  will  have  only  a  minor  effect  on  the  quality  of  the  display.  Again, 
a  value  of  zero  indicates  a  very  small  true  value,  so  the  displayed  value  of 
closest  approach  altitude  will  be  reasonably  accurate. 

• 

Unfortunately,  fluctuations  in  p  will  cause  serious  variations  in  the 
value  of  t  from  scan  to  scan,  leading  to  lack  of  confidence  in  its  displayed 
value  by  the  pilot.  Furthermore,  if  the  closing  rate  of  the  threat  aircraft 


is  small  enough  to  produce  a  p  of  zero,  an  infinite  t  will  be  computed, 
an  improved  formula  for  x  is  required. 


Thus, 


The  improved  formula  is  based  on  the  fact  that  the  vector  dot  product  is 
equivalent  to  the  projection  of  one  vector  on  the  other.  The  relevant 
identity  is  this  case  is: 


P  *  vrel  =  “PP 
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Thus,  formula  (6)  is  converted  to: 


x  =  -  sin2  0 
P 


P  *  vrel 


-p2  sin2  q 


p  (sin  B)  v  (sin  h)  +  p  (cos  B)[v  cos  h  -  s] 


-p  sin2  0 


v  cos  (B~h)  -  s  cos  0 


Finally,  seeing  from  Fig.  2  that: 

d  /p"2  —  m2 

sin  0  =  -  =  - 

P  P 


the  result  can  be  expressed  as: 


(p2  -  m2) 

t  -  (8) 

p [s  cos  3  -  v  cos  (S-h)] 


As  this  formula  involves  only  cosines,  a  simple  table  lookup  function,  -i 
microcomputer  can  be  used  to  compute  the  value  of  x. 

With  a  16-bit  microcomputer,  which  permits  32-bit  integers,  equation  (8) 
can  be  computed  as  written.  However,  with  an  8-bit  microcomputer  such  as  used 
in  the  Lincoln  ATARS  system,  several  intermediate  results  can  easily  exceed 
the  16-bit  integer  limit.  To  see  this,  the  equation  must  be  rewritten 
according  to  the  least  significant  bit  values  of  each  quantity: 
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T 


E(p/5)2  -  (o/5)2] 


(p/5)  *  {(s/360)  *  (cos  8)/128  -  (v/360)  *  [cos(6-h) 3/128} 


128  *  360  *  (p 2  -  m2) 

T  - - 

5*p*[s  cos  6  -  v  cos  (8  -  h)] 


(9) 


where  p,  m,  s,  and  v  are  now  in  uplink  values 
The  constants  arise  as  follows: 

1.  since  a  microcomputer  is  an  integer  machine,  the  fractional 
cosine  values  must  be  scaled  0  to  128 

2.  converting  speeds  in  10  knot  lsb  uplink  units  to  speeds  in 
miles/second  involves  a  division  by  360 

3.  the  range  and  miss  distance  are  each  scaled  in  0.2  mile  lsb  units  in 
the  uplink  message,  necessitating  a  division  by  5  to  get  miles 

In  an  8-bit  machine,  the  best  order  of  computation  steps  is  thus: 


D  =  s  cos  8  -  v  cos  (8~h) 

128  *  360  +  D/2 

F  =  [ - ] 

D 

t  =  F*p/5  -  [F*m2/5]/p  (10) 


where  the  D/2  term  provides  more  accurate  roundoff. 

Formula  (10)  is  not  as  accurate  as  formula  (8)  because  of  integer 
division  roundoff  errors,  particularly  in  the  calculation  of  F.  However,  the 
percentage  error  in  the  computed  t  is  reasonably  small,  reaching  a  maximum  of 
only  10%  for  a  700  knot  closing  encounter. 

Sensitivity  of  x  to  Data  Truncation 

Although  equation  (8)  is  far  superior  to  equation  (6)  with  respect  to 
sensitivity  to  uplink  data  truncation,  it  will  still  be  affected  to  some 
degree  by  this  phenomenom.  To  determine  how  serious  the  error  can  be,  a 
computer  program  was  developed  to  test  several  representative  threat 
scenarios:  a  near  head-on  collision,  a  90°  closing  situation,  and  a  shallow 
closing  angle  situation. 


For  each  closing  geometry,  both  slow  (120  knot)  and  fast  (360  knot) 
aircraft  were  considered  for  the  own  and  threat  aircraft,  yielding  four 
different  cases.  The  results  indicated  that  only  when  both  aircraft  were  slow 
did  any  significant  computation  error  occur  for  t.  This  result  is  reasonable, 
as  the  quantities  p,  v,  and  s  are  smallest  for  this  case,  and  thus  most 
subject  to  large  percentage  truncation  errors. 

Figures  A3,  A4,  and  A5  present  sequences  of  onboard  t  values  that  would 
be  computed  for  sample  slow  aircraft  threat  encounters.  In  each  figure,  two 
sequences  are  provided:  the  first  for  128  knot  aircraft  and  miss  distance 
of  0.35  miles,  the  second  for  122  knot  aircraft  and  a  miss  distance  of  0.45 
miles.  Thus  both  large  and  small  truncation  cases  for  these  quantities  are 
shown. 

These  figures  demonstrate  that  large  errors  in  t  and  a  non-monotonic 
countdown  with  time  are  major  issues  only  with  the  shallow  encounter.  This  is 
again  reasonable  because  of  the  smaller  values  of  p  for  this  geometry,  leading 
to  greater  percentage  truncation  effects. 

Although  the  sequences  of  x  in  Fig.  A5  have  several  anomalies,  such  as 
large  jumps  and  occasional  increases,  the  displayed  values  are  in  no  case 
wildly  different  from  the  actual  ones.  Thus,  it  appears  that  an  onboard 
computation  of  the  time  to  closest  approach  is  feasible. 

Sensitivity  of  t  to  Tracker  Errors 

The  previous  sections  have  concluded  that  the  airborne  values  of  times  to 
closest  approach  will  be  approximately  as  good  as  those  computed  on  the 
ground.  However,  this  fact  would  be  irrelevant  if  the  latter  values  had  large 
inaccuracies  due  to  errors  in  the  sensor  tracker.  In  that  event,  the  entire 
concept  of  a  relative  motion  display  would  be  questionable.  This  section  will 
briefly  attempt  to  investigate  the  expectable  errors  in  t  for  realistic 
trackers. 

The  first  issue  to  consider  is,  assuming  the  tracker  has  accurate  data  on 
both  of  the  aircraft  (speeds,  headings,  locations),  what  affect  will  scan  to 
scan  tracker  noise  have  on  the  sequence  of  values  of  x  it  computes.  If  this 
noise  is  magnified,  and  large  jumps  or  reversals  in  x  are  expected,  the  time 
data  would  only  confuse  the  pilot. 

A  computer  program  analyzed  this  question  by  introducing  Gaussian  noise 
into  the  tracker  measurements  on  each  scan  for  the  trajectories  shown  in 
Figs.  A3,  A4,  and  A5.  The  assumed  data  variances  were  1°  for  each  heading,  2% 
for  each  velocity,  and  60’  for  the  range.  It  assumed  further  that  the  errors 
were  independent  from  scan  to  scan,  which  tended  to  exaggerate  the  errors 
produced  in  x.  Even  so,  the  results  were  that,  in  all  cases,  no  error  greater 
than  2  seconds  occurred  for  x.  Thus,  in  particular,  the  values  of  x  always 
decreased  from  scan  to  scan.  These  results  indicate  that  tracker  noise  is  not 
a  problem. 
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Fig.  A3.  Near  Head-on  Collision 
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Fig.  A4.  90°  Closing  Geometry 


The  second  issue  to  consider  is  the  effect  that  tracker  biases  will  have 
on  the  closest  approach  data,  either  miss  distance  on.  If  an  aircraft  has 
been  turning,  or  if  its  track  is  new  to  the  sensor,  bias  errors  as  large  as 
the  following  are  possible: 

heading:  15° 

thus,  relative  heading:  30° 
and  bearing:  15° 

velocity:  15% 

range:  0.2  miles 

Furthermore,  since  velocity  information  is  transmitted  on  the  uplink  only  at 
the  start  of  a  threat,  the  onboard  computation  could  be  using  velocities  as 
much  as  25%  in  error. 

A  computer  program  calculated  the  values  of  miss  distance  and  t  for  each 
trajectory  with  these  assumed  errors.  Not  surprisingly,  the  values  showed 
large  errors  were  possible  for  both  in  all  cases.  The  errors  were 
particularly  bad  when  slow  speed  aircraft  were  in  conflict,  and  for  all 
aircraft  cases  in  the  shallow  encounter. 

The  potential  for  such  large  errors  has  been  recognized  by  MITRE  in  their 
ATARS  ground  algorithms.  In  particular,  they  allow  for  the  existence  of 
heading  errors  by  computing  the  worst  case  T  under  the  assumption  that  the 
aircraft  may  be  turning.  Also,  a  range  guard  is  used  to  aid  in  detecting 
shallow  angle  threats. 

Normally,  tracker  errors  will  be  far  smaller  than  those  postulated  above. 
Thus,  the  relative  motion  display  and  sequence  of  values  of  x  should  be  a 
usable  pilot  aid.  However,  only  extensive  flight  testing  could  prove  this 
point. 

Conclusions 

This  appendix  has  demonstrated  that  the  location  of  the  closest  point  of 
approach  and  the  expected  time  t  until  it  is  reached  can  be  computed  by  a 
microcomputer  in  the  onboard  ATARS  display  system  on  the  second  and  subsequent 
scans  of  a  threat  encounter.  Thus,  a  relative  motion  display  is  possible  with 
the  current  uplink  message  formats. 

The  formula  for  x  is  affected  to  some  degree  by  uplink  data  truncation, 
but  the  results  are  well  within  the  usable  area.  Also,  an  8-bit  microcomputer 
can  perform  the  necessary  computation. 

Finally,  ground  tracker  errors  can  strongly  affect  the  values  of  miss 
distance  and  x.  Only  a  flight  test  program  can  answer  whether  these  effects 
seriously  hamper  the  usefulness  of  relative  motion  information. 
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